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

Closed
rufuspollock opened this Issue Sep 24, 2015 · 13 comments

Projects

None yet

4 participants

@rufuspollock
Contributor

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 rufuspollock self-assigned this Sep 24, 2015
@rufuspollock
Contributor

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

@rufuspollock
Contributor

@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
Member

@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
Contributor

@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
Contributor

@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
Contributor

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
Member

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
Contributor

@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
Contributor

@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
Member

👍 rdfType in that case.

@rufuspollock rufuspollock added a commit that closed this issue Jan 30, 2016
@rufuspollock rufuspollock [jts][m]: add rdfType property to field descriptor - fixes #217.
* Provides support for rich descriptions of data in fields.
bd50a57
@danfowler danfowler referenced this issue in frictionlessdata/schemas Jul 28, 2016
Closed

Add "rdfType" field property #51

@danfowler danfowler added a commit to frictionlessdata/schemas that referenced this issue Jul 28, 2016
@danfowler danfowler Add "rdfType" field property 36b9941
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment