TDDs need to deal with missing @type

[mmccool]

Since @type is optional in TDs, if it is missing it should be inferred as "Thing". Perhaps this should be an official default value in the TD? Could also be part of canonicalization.

[farshidtz]

I believe generic TDDs are type agnostic. So this is probably not something that they need to worry about.

[AndreaCimminoArriaga]

The lack of the @type Thing was hindering the SHACL shape validation since the shape was defined for resources with that type. I think having it as default value is a good idea. Another scenario where missing the type could hinder some task is in discovery, if the type is not specified SPARQL queries could not retrieve resources that are td:Thing (unless inference is used).

As a good practice I would always have the @type Thing in the json-ld of the thing descriptions, either automatically injected or provided by the user.

[mmccool]

The problem is RDF databases. Similarly to a missing @id, an @type needs to be inferred if none is given. And similar to the issue with @id, if we add something to the TD when it gets registered with the database, it won't technically be identical to what was registered.

[mmccool]

Also an issue: what if we get a file with a different @type than we expect (eg a ThingModel).

[mmccool]

Proposal:

• A TDD adds a "Thing" @type by default to a TD during registration if it is missing.
• We could make this part of canonicalization (not a special kind of default, but not really) so signing is not broken

[benfrancis]

I suggest that @type should always be optional, even when storing a Thing Description in a directory, since the default serialisation of a Thing Description is plain JSON, not JSON-LD.

A default @type of Thing can be applied by a consumer if @type is missing, when parsing a Thing Description as JSON-LD.

[mmccool]

Consensus (from 8 Nov meeting):

1. Making it a default is possible, and we can propose this in the TD spec. -- TD spec issue/PR needed.
2. In practice, the default can be inserted only in RDF contexts that need it for TDD purposes. In particular: 3 and 4.
3. Inserting @type as "Thing" JUST before SHACL validation if @type is missing solves the SHACL problem. This change should not be inserted into the database. This is also relevant to other instances of SHACL validation so maybe should be mentioned in the TD spec. --> TD spec PR needed.
4. To solve the SPARQL problem, we can say that before framing (for export) the @type Thing is inserted if @type is missing (and then deleted before the JSON-LD is returned). SPARQL queries will just have to be written to take into account that @type may be missing (but everything in a TDD is known to be a Thing, so...). This should be added to the Discovery spec for SHACL queries (as informative notes on how implementations should deal with missing @type. --> Discovery spec PR needed.
5. But... 2 and 3 are hacks, and for TD 2.0 we should make @type mandatory (and maybe "ThingDescription", not "Thing..."; that is a separate issue). --> TD 2.0 issue needed.

[mmccool]

Seems resolution is NOT to add @type, but an implementation using SPARQL "injects" it when needed during implementation. We don't have to change the spec at this point; it's an implementation choice/detail.

Would be good to be clearer about this in the next spec, since it might impact signing etc. if an @type magically appears, so we might want to explictly forbid it. Relates to #257