Re: Specify how terms are treated when they are not specified in the context (ISSUE-56)

On Jan 12, 2012, at 6:44 AM, Markus Lanthaler wrote:

>> This is certainly an interesting question. I suspect that we can look
>> at the ongoing work on how microdata resolves keys, i.e. append to or
>> resolve against a given type. Or to resolve them against the base IRI,
>> as I believe your example suggests.
> 
> The example shows what the spec defines currently, it treats them as
> relative IRIs.
> 
> 
>> (I personally would have liked to
>> have kept @vocab around for this though.)
> 
> This was one of the reasons why I was in favor of dropping it :-)
> 
> 
>> In any case, the first
>> question is whether we should create IRIs at all for such keys, or to
>> drop them completely (along with any values they hold).
> 
> That's exactly the question I'm asking. I would argue we should *not*
> automatically create IRIs for all keys. Whether we drop the values they hold
> is another question.
> 
> I think we should not! We should just recursively step into that data and as
> soon as we are able to create a new triple we should create that. This
> triple would of course be in a different graph so to speak. What I mean is
> that it is not automatically connected to any triple above it in the tree.
> So in the example that would mean the initial blank node will not be created
> as the data under "data" is not connected to it.

In the case of {"data": "foo"}, even if "data" isn't mapped, it is a valid relative IRI, so if the document was loaded from http://example.com/doc/, it would expand to http://example.com/doc/data. This is also common practice in languages such as Turtle, where it is common to use relative IRIs. Even in the case where there is no base IRI (typically just examples), it's common to see the following:

    <> a foaf:PersonalProfileDocument;
       foaf:maker <#me>;
       foaf:primaryTopic <#me> .

    <#me> a foaf:Person .

In JSON-LD, this would look like the following:

    {
      "@context": {...},
      "@id": "",
      "@type": "foaf:PersonalProfileDocument",
      "foaf:maker": "#me",
      "foaf:primaryTopic": {
        "@id": "#me",
        "@type": "foaf:Person"
      }
    }

This doesn't address IRI expansion for properties, but we pulled back from having specialized IRI processing based on the position, and I don't think we should start now.

In the Microdata to RDF spec, we also have to deal with properties without an IRI mapping. In that case, we mint them using the microdata namespace, but I'd rather not go there for JSON-LD.

>> This brings to mind something very related which I've been thinking
>> about recently. I intend to file an issue about the @rev that I've
>> proposed for representing incoming links to a node (for use in framed
>> data). Alas, based on discussion we've had about it on the list, I
>> fear that it might be a hard sell. Therefore I've been thinking that
>> we should at least support a way of explicitly declaring "no-op" or
>> "null" keys. That is, keys can be explicitly bound to null (or perhaps
>> "@comment"). These keys and any values they hold would then be
>> completely ignored. That way I can merrily "extend" my data with this
>> mechanism, while being 100% compliant to JSON-LD since it would be
>> dropped.
> 
> Would the use case you have in mind be supported by the approach I've
> proposed above?

I think the way to deal with this is to define that an IRI mapping to _null_ explicitly causes that value (and all descendant nodes) to be ignored. We can add to the initial context that "@comment" is mapped to _null_.

Gregg

> --
> Markus Lanthaler
> @markuslanthaler
> 
>

Received on Thursday, 12 January 2012 18:14:34 UTC