Re: Forms and principles of the JSOD-LD context

Hi Markus!

I'll make some comments and clarifications.


2011/10/31 Markus Lanthaler <markus.lanthaler@gmx.net>:
>> I actually added an example based on the telecom discussion in an issue
>> [1]
>>
>> {
>>   "@context":
>>   {
>>     "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
>>     "xsd": "http://www.w3.org/2001/XMLSchema#",
>>     "name": "http://xmlns.com/foaf/0.1/name",
>>     "age":  {"@iri": "http://xmlns.com/foaf/0.1/age", "@coerce":
>> "xsd:integer"},
>>     "homepage": {"@iri": "http://xmlns.com/foaf/0.1/age", "@coerce":
>> "@iri"},
>>     "currentProject": {"@iri":
>> "http://xmlns.com/foaf/0.1/currentProject", "@coerce": ["@iri",
>> "@list"]},
>>   },
>>   ...
>> }
>
> How is that going to affect the processing? Currently prefixes are allowed
> in coercion rules but not in the context itself. If we switch to this
> condensed form we might run into some troubles at it opens the door for
> nasty recursions.

I don't think that there would be any risk of recursion. If you first
parse the top level key-value pairs in @context, and then resolve the
inner objects against that, I believe everything would work.

In fact, I might be open to resolving even top values, i.e. the IRIs
terms are bound to (and @iri values for terms were we to accept them)
against the keys, so that one could use CURIEs to reduce the
repetition of vocabulary base IRIs. Granted, reflexive references
would fail, and this might call for the use of a separate @prefix
section. It wouldn't be required though. However, I am also interested
in seeing what can be done to facilitate CURIE-free JSON-LD contexts,
so I'm wavering on this particular idea..


> Another thing, isn't @coerce in this case exactly the same as @datatype (or
> @type if we merge them)?

No, I not here. Since this isn't instance data but declarations of
terms, it don't think using @datatype would make sense (because these
aren't literals). @coerce may be a bit more like rdfs:range if
anything, but here more of an imperative. And since this isn't about
declaring RDF data about the properties and classes themselves, I'd
refrain from any such parallells (the context just defines usage).
This might be one problem of using @iri here. In fact, were it not for
the potential confusion of introducing a "local namespace" for term
objects, I'd probably recommend to use "iri" and "coerce" without the
special "@" sign here..

Of course, maybe you meant that we could reuse @datatype in this
*different* situation, and thus remove the need for the separate
@coerce key? Even if so, I think it'd endanger the understanding of
what's going on. In fact, I'd might rather replace @iri here with
something like @mapsTo. Just to clarify that it is a mapping we're
doing, and not instance data. I think this warrants some discussion.
In general, I think reuse of terms can be dangerous where precision
and clarity is needed. That's certainly the case in context
definitions. When on such a meta level, I'd much rather use specific
terms than overload anything. (In the same way, using @type would be
even more confusing, since it'd then look like we're describing the
property or class -- and hence could be expected to @type them with
rdf:Property or owl:Class. I.e. far from our intent!)


>> > We could instead use a form where values can either be the IRI string
>> > for the term, or an object defining both the @iri (or none to resolve
>> > it to @vocab) and a @coerce rule. Like:
>> >
>> >    "@context": {
>> >        "@vocab": "http://purl.org/dc/terms/",
>> >        "created": {
>> >            "@coerce": "dateTime"
>> >        },
>> >        "creator": {
>> >            "@coerce": "@iri"
>> >        },
>> >        "identifier": {
>> >            "@coerce": "string"
>> >        },
>> >        "issued": {
>> >            "@coerce": "date"
>> >        },
>> >        "updated": {
>> >            "@coerce": "dateTime"
>> >        },
>> >        "label": "http://www.w3.org/2000/01/rdf-schema#label",
>> >        "Document": "http://xmlns.com/foaf/0.1/Document",
>> >        "primaryTopic": {
>> >            "@iri": "http://xmlns.com/foaf/0.1/primaryTopic",
>> >            "@coerce": "@iri"
>> >        }
>> >    }
>>
>> Other than the fact that "dateTime", "string", and "date" have no
>> defined meanings, I see value in this. It can be inferred the if
>> there's an @vocab, then prefixes without a defined IRI are considered
>> to be within that vocabulary and IRI expansion takes place.
>
> That's actually something that made me think that dropping @vocab (and
> perhaps also @base) would be a quite good idea [ISSUE-26]. I think using
> @vocab will result in a lot of messy/wrong data as terms will be used
> regardless of whether they are in the vocabulary or not.

Sorry about the confusion; as I just explained in my response to
Gregg's feedback I was aware of not having added the proper xsd
references, but I forgot to put that in before posting. In any case,
this didn't stem from me being confused about @vocab -- I believe it
has strong merits and would not like to see it removed. (Anyway,
that's a separate issue.)


>> Thanks for your thoughts. I can see some real advantages in
>> consolidating this information, and it seems to follow given that we're
>> already inclined to reverse the sense of @coerce relations.
>
> +1

Great! Thanks for your feedback.

Best regards,
Niklas

Received on Tuesday, 1 November 2011 00:07:34 UTC