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

Hi Markus!

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. (I personally would have liked to
have kept @vocab around for this though.) 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).

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.

(Note that in my use case I only *need* this for representing a
relevant chunk of tripes as usable JSON (also indexed in
ElasticSearch), not really for converting such JSON back to RDF
(though I'd certainly welcome it). Therefore I'd be ok with such data
being a "comment".)

Best regards,
Niklas


On Thu, Jan 12, 2012 at 2:27 PM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
> I've just filed the following issue and would like to hear your opinion on
> it.
>
> -----
>
> The syntax spec currently says that [1]:
>
> "JSON-LD defines a mechanism to map JSON terms, i.e., keys and values, to
> IRIs. This does not mean that JSON-LD requires every key or value to be an
> IRI, but rather ensures that keys and values can be mapped to IRIs if the
> developer desires to transform their data into Linked Data."
>
> And I think it is a design decision that we allow mixing plain old JSON with
> linked JSON. Nevertheless, according to the API spec a key is *always*
> converted to an IRI even if that means to interpret the value directly as an
> IRI. For example the following JSON-LD document:
>
>    {
>      "@context": { "foaf": "http://xmlns.com/foaf/0.1/" },
>      "data": [
>        {
>          "@id": "_:bnode1",
>          "@type": "foaf:Person",
>          "foaf:homepage": "http://example.com/bob/",
>          "foaf:name": "Bob"
>        },
>        {
>          "@id": "_:bnode2",
>          "@type": "foaf:Person",
>          "foaf:homepage": "http://example.com/eve/",
>          "foaf:name": "Eve"
>        },
>        {
>          "@id": "_:bnode3",
>          "@type": "foaf:Person",
>          "foaf:homepage": "http://example.com/manu/",
>          "foaf:name": "Manu"
>        }
>      ]
>    }
>
> where "data" was intentionally not mapped to an IRI is translated to the
> following Turtle document:
>
>    _:c14n0
>       <data>
>          _:c14n1,
>          _:c14n2,
>          _:c14n3.
>    _:c14n1
>       <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
> "http://xmlns.com/foaf/0.1/Person";
>       <http://xmlns.com/foaf/0.1/homepage> "http://example.com/bob/";
>       <http://xmlns.com/foaf/0.1/name> "Bob".
>    _:c14n2
>       <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
> "http://xmlns.com/foaf/0.1/Person";
>       <http://xmlns.com/foaf/0.1/homepage> "http://example.com/eve/";
>       <http://xmlns.com/foaf/0.1/name> "Eve".
>    _:c14n3
>       <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
> "http://xmlns.com/foaf/0.1/Person";
>       <http://xmlns.com/foaf/0.1/homepage> "http://example.com/manu/";
>       <http://xmlns.com/foaf/0.1/name> "Manu".
>
>
> ---
>
> [1] http://json-ld.org/spec/latest/json-ld-syntax/#linking-data
>
>

Received on Thursday, 12 January 2012 14:14:40 UTC