New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
4 participants
@rufuspollock
Contributor

rufuspollock commented Sep 24, 2015

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

This comment has been minimized.

Contributor

rufuspollock commented Nov 17, 2015

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

@rufuspollock

This comment has been minimized.

Contributor

rufuspollock commented Nov 17, 2015

@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

This comment has been minimized.

rossjones commented Nov 17, 2015

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

This comment has been minimized.

Member

jpmckinney commented Nov 17, 2015

@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

This comment has been minimized.

Contributor

rufuspollock commented Nov 17, 2015

@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

This comment has been minimized.

rossjones commented Nov 17, 2015

@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

This comment has been minimized.

Contributor

rufuspollock commented Nov 17, 2015

@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

This comment has been minimized.

Contributor

rufuspollock commented Jan 21, 2016

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

This comment has been minimized.

Member

jpmckinney commented Jan 21, 2016

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

@timgdavies

This comment has been minimized.

timgdavies commented Jan 21, 2016

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

This comment has been minimized.

Contributor

rufuspollock commented Jan 28, 2016

@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

This comment has been minimized.

Contributor

rufuspollock commented Jan 28, 2016

@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

This comment has been minimized.

Member

jpmckinney commented Jan 28, 2016

👍 rdfType in that case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment