"Semantic" type (datatype) field in JSON Table Schema

[rufuspollock]

Propose to implement a semantic / url based type field in JSON Table Schema.

Naming options:

rich[Data]Type
semantic[Data]Type
# like this because we retain sort order
type[type]Semantic
rdfType
rdfClass

Definition: this is a richer description of the "type" of data in a given column, for example that this fields is not just a string but is the name of a place, or even, the name of a US state. The field value MUST be a url/uri (?) and this SHOULD dereference either to a human or machine readable description, or, preferably be an RDF class.

Questions:

• Does the URL need to point to an RDF class? Obvious reasons why yes but several people have said "no" this should stay generic.
• We could drop url requirement and just have this be some rich type that it is up to users how it resolves ...

[rufuspollock]

I think increasingly we only support pointing to rdf classes etc and that this is therefore named rdfType or typeRdf or datatypeRdf

[rufuspollock]

@jpmckinney @morty @rossjones @pwalsh @danfowler @timgdavies any thoughts here. I've wanted to add this for a while so plan to get this in soon.

[rossjones]

Is this not what the context field is for in JSON-LD? Is that what you're thinking of adding (either the actual context or something that does the same job)?

[jpmckinney]

@rossjones Do you mean that users of JSON Table Schema would add their own @context property at the top-level of their schema, in order to give meaning to their fields' type properties? I guess that's one option for satisfying "We could drop url requirement and just have this be some rich type that it is up to users how it resolves ..." (in this case, the @context resolves the values of the type properties).

However, overloading the type field for use both for the simple types built into JSON Table Schema and for the complex types available via RDF seems undesirable. I think there would need to be a new field in addition to type. Maybe we can call it narrowerType? (SKOS uses the term narrower to relate concepts.)

[rufuspollock]

@rossjones i thought we could use @context or @type originally for this but I don't think we can, at least not conveniently - see lengthy discussion in #89

Note the idea of having a general @context for entire datapackage.json is a separate issue in #218

[rossjones]

@jpmckinney Pretty much what you suggest in your first paragraph, but I'd be against adding more fields as well as type, so perhaps not the best solution. I don't like the idea of type being a string describing a simple type, or a url describing a possibly more complex one. I like the suggestion made by @ldodds at #89 (comment)

@rgrp Can open, worms everywhere! Not sure I want to get dragged into the finer details of JSON-LD, but if things can be re-used without major breakage, I can't see a reason why not if it increases usefulness to linked-data people.

[rufuspollock]

@rossjones the logic here is that we could definitely provide a JSON-LD context here and that could label this rdfType - however i also want a really simple way for users to point to richer types and thought a single property would be nice (and could even be used by those not versed in the finer details of JSON-LD).

I don't like the idea of type being a string describing a simple type, or a url describing a possibly more complex one.

Note definite idea is to have a separate property from type for this "rich type" - we won't be overloading type

[rufuspollock]

OK, I think we are ready to proceed here. Final question is naming of property. Interested in votes between:

rdfType
rdfClass

Or votes for other options if people do not like this.

[jpmckinney]

I had a suggestion for "narrowerType" in case there was still a desire to keep the values/range generic.

[timgdavies]

Would @type be consistent with JSON-LD language here? I realise that is close to type, but should be distinct enough for users to tell between them.

[rufuspollock]

@timgdavies good suggestion. We thought about it a lot but apparently there is some sort of issue of how this works with JSON-LD - see the very long discussion in #89. that's why we're pursuing this explicitly "rdf" item.

[rufuspollock]

@jpmckinney i like the idea and perhaps we will have that if we decide we want something beyond RDF. At the moment, it seems to me like restricting to RDF is good when we do not know what more generic type sets we would want to refer to. At the moment i'm inclined to rdfType to be consistent with type.

[jpmckinney]

👍 rdfType in that case.