RE: Comments on rdf11-json

On Wednesday, July 03, 2013 1:22 AM, Pierre-Antoine Champin wrote:
> 8/ A. Internet media type, type name: should be "application" and not
> "text"

Is it even possible to register a media type for a W3C Note? I don't think
so. Thus, this whole section should be removed IMO.


> Meta-remark:
>
> It would be nice if, instead of proposing an alterative format to
> JSON-LD we could propose a controlled subset of JSON-LD that meets the
> requirements that this format addresses.

Fully agreed. Currently, flattened, expanded JSON-LD addresses this. The
only thing it doesn't support is indexing by subject. There's however an
internal data structure (node map) created by the JSON-LD algorithms that
does that as well. We don't expose since it isn't valid JSON-LD.


> I understand that this format 1) has some advantages over JSON-LD
> (less variability, easy access to a given triple...), and 2) is
> already deployed in some applications. I'm not sure which one, of 1 or
> 2, is the strongest argument for publishing this note. If this is 1,
> why not propose something with the same advantages, by compatible with
> JSON-LD?

> For exemple, instead of
> 
> [...]
> 
> one could write
> 
> { "http://example.org/S": {
>     "@id": "http://example.org/S",
>     "http://example.org/P": [
>       { "@id": "http://example.org/O"
>       },
>       { "@id": "_:b1"
>       },
>       { "@value": "a literal",
>         "@language": "en"
>       },
>       { "@value": "a literal",
>         "@datatype": "http://example.org/DT"
>         }
>     ]
>   }
> }
> 
> As far as I can tell, this is valid JSON-LD, provided with the
> appropriate @context -- I would require a confirmation form JSON-LD
> experts, though...

Unfortunately it's not that easy. Your example produces one extra-triple:

   [] <http://example.org/S> <http://example.org/S> .

We would need to add some mechanism to allow an @index-container at the
top-level. Currently, that's only allowed for specific properties. In almost
all cases that's not a problem because there's a single top-level object
(most of the time the node corresponding to the document's URL) and from
there on everything can be indexed.

An alternative would be to use a bnode-predicate to instantiate that
container. Such data would be discarded (or skolemized) when transformed to
standard RDF (i.e., not generalized RDF):

{
  "@context": {
    "data": { "@id": "_:data", "@container": "@index" }
  },
  "http://example.org/S": {
    "@id": "http://example.org/S",
    "http://example.org/P": [
      { "@id": "http://example.org/O" },
      { "@id": "_:b1" },
      { "@value": "a literal", "@language": "en" },
      { "@value": "a literal", "@type": "http://example.org/DT" }
    ]
  }
}

Here's the link to the output in N-Quads: http://bit.ly/10yQJ31


> I even think that the JSON-LD subset could be made to look even closer
> to the original format, for example by stating in the implicit context
> that "lang" is equivalent to "@language", and "datatype" to
> "@datatype" (but "value is a problem, sometimes meaning "@id"; and
> sometimes "@value").

Exactly (btw. it's @type not @datype).


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 3 July 2013 08:16:41 UTC