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

> 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.

> 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?


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 12 January 2012 14:51:43 UTC