Re: Forms and principles of the JSOD-LD context

Hi all!

This is a good discussion. I hope we can make something definitive of the idea.

2011/11/2 Markus Lanthaler <markus.lanthaler@gmx.net>:
>> > I looked at it more from a programmers perspective (and I think a lot
>> of
>> > people that will eventually use JSON-LD do). If consider the context
>> as kind
>> > of a header file where all variable declarations are made, I think it
>> would
>> > make sense. So you basically say: In the context (that's the
>> "header") I set
>> > up and declare everything that I'll then use in the main JSON-LD
>> document,
>> > i.e., I map terms and prefixes to IRIs and set their data type. I
>> think
>> > programmers won't have any problems in understanding that the context
>> isn't
>> > about instance data. Even more so if they use external context
>> documents. On
>> > the other hand, the term coercion is typically used to refer to
>> implicit
>> > (automatic) type conversions in programming.
>>
>> Agreed, introducing more keywords will only confuse. Programmers will
>> intuit meaning based on context (no pun intended). Probably the same
>> reasoning goes for using @type instead of @datatype both in literals
>> and to replace @coerce in the term definitions.
>
> Yes, I think so. That's exactly the reason why proposed merging @type and
> @datatype in the first place.


First off, I wouldn't like to merge this discussion with the one about
merging @type and @datatype. Let's handle that in the separate thread.

In any case, I am very wary about using the same term in different
contexts to denote *different* things. I agree that programmers (and
people in general) usually can handle that, but it can make things
very tricky. For instance, examples have to make it clear that they
outline a particular item (say a term declaration) within the
"@context", unless it is fairly obvious in the example. Also, in
particular, "datatype" doesn't really capture the nature of how we
coerce. We have "@iri" and "@list" as well, both very different from
datatypes, instead controlling how to interpret the object as a
resource (not a literal).

However, we have another option which let's us avoid this particular
problem entirely! Instead of using an object with special keys to
define a term as a combination of iri and coercion, we can define this
combined form to look like this:

    "created": {"http://purl.org/dc/terms/created": "xsd:dateTime"}

That is, the object for the term is a dictionary where the key
represents the IRI, and the value defines the coercion (or coercions).
This becomes very succinct, but I find it quite readable and
understandable. While it doesn't open up for more features, I suspect
that that is a good thing. (And I can still work my needs of sets and
possibly rev keys into coerce tokens.)

Here's a more complete example:

    "@context": {
      "title": "http://purl.org/dc/terms/title",
      "description": "http://purl.org/dc/terms/description",
      "identifier": {"http://purl.org/dc/terms/identifier": "xsd:string"},
      "publisher": {"http://purl.org/dc/terms/publisher": "@iri"},
      "created": {"http://purl.org/dc/terms/created": "xsd:dateTime"},
      "authorList": {"http://purl.org/ontology/bibo/authorList":
["@list", "@iri"]}
    }

I find this quite appealing.

I've tried this out, combined with what Gregg suggested: that we might
be able to use a *list* of contexts with different "@vocab" values in
each to make things more compact.

That of course requires that terms/curies in right-hand values are
allowed (to be resolved against the same context). I implemented that
as well, in the process noticing that even in the current context
form, the "@coerce" block depends on the parent context. So the
streaming issue is there regardless (and I think it can be overcome by
other means -- for instance by using precisely this list form (or
"chain of contexts" if you will)).

Our system now supports both the current form with a disconnected
"@coerce" section, like:

    <https://raw.github.com/rinfo/rdl/1c8c6d2/packages/java/rinfo-service/src/main/resources/json-ld/context.json>

, and the latter form I here suggest, using combined term directives.
It also supports reading a "@context" list as described (in order, the
keys of the last object overrides eventual keys in preceding objects).
Combining these makes this work:

    <https://raw.github.com/gist/1340408/context-vocab-array-combined-iri-coerce.json>

Notice here that the IRI values in the combined form are mostly
exactly the same as the key term, since they are resolved against
@vocab. Given that we already have this repetition (in the leaf of
every bound IRI), and that I don't find this "mirror" effect
particularly disturbing, I think that it is fine. Also, notice that
each context object is to be interpreted at a time (so that each
"@vocab" works as expected within its context object). And finally
that, according to the merge order, the last object (where vocab is
"http://rinfo.lagrummet.se/ns/2008/11/rinfo/publ#") defines the vocab
for any instance document referring to this context document.

I know, I've gone and made this into a two-piece suggestion. Consider
the "combined term form" as one, and the "chain of vocab-altering
contexts with resolvable right-hand IRIs" as another. (Granted, I find
that they work very well together.)

What do you think?

Best regards,
Niklas

Received on Friday, 4 November 2011 21:21:34 UTC