lapps / vocabulary-pages

DSL files and templates used to generate the LAPPS WS-EV pages.
Apache License 2.0
0 stars 0 forks source link

Discriminators and the context #62

Open marcverhagen opened 6 years ago

marcverhagen commented 6 years ago

In our json-ld we use keys like views and then the context at http://vocab.lappsgrid.org/context-1.0.0.jsonld neatly expands it to a full URI in the vocabulary (at least, the LIF part of it, and views is expanded to http://vocab.lappsgrid.org/interchange/views, although, that URL does actually not exist, which may warrant its own issue).

There was, in my mind at least, un unwritten and unspoken intention of adding things like upenn-tagset so we could simply put that in the view metadata and have the context expand it. We are actually not doing this in the context and the good this is that We Should Not Do That anyway. Short names like token and pos will be expanded, but these are special in that they are in our vocabulary proper (as in, just the linguistic categories). In all other cases we need to use the full name in the LIF object.

This begs the question of course on what those short names are good for.

marcverhagen commented 6 years ago

We do not want to update the schema each time we come up with a short name. We could add

"tagset" : "http://vocab.lappsgrid.org/ns/tagset/",

But we forgot whether we can then use tagset/pos#brown and have it expand to http://vocab.lappsgrid.org/ns/tagset/pos#brown.

This is probably a non-issue. We could restrict the value to a URI but what harm is there in a string, it could contain all kinds of valuable information including URLs.

But if we do not have something like the expansion from tagset then we do need to make sure that services use full URIs when they add a tagset to the metadata.

marcverhagen commented 6 years ago

This is somewhere in https://w3c.github.io/json-ld-syntax/#the-context:

Properties, values of @type, and values of properties with a term definition that defines them as being relative to the vocabulary mapping, may have the form of a relative IRI, but are resolved using the vocabulary mapping, and not the base IRI.

No idea what that properties with a term definition refers to, but we can use @type and do something like

{
  "@context": {
    "pos": "tagset:pos/",
    "tagset": "http://vocab.lappsgrid.org/tags/" },
  "tagset": { "@type": "pos:penn" }
}

which would expand to

{
  "http://vocab.lappsgrid.org/tags/": {
    "@type": "http://vocab.lappsgrid.org/tags/pos/penn" }
}

This would be proper use of JSON-LD, but we are not doing that elsewhere (for example the posTagSet meta data attribute) so let's stick to the old approach. Note also that the vocabulary says the value is a String or a URI and when using @type the former becomes problematic .