Re: JSON-LD Spec updated

On 06/16/2011 01:22 AM, Gregg Kellogg wrote:
> I  updated the JSON-LD spec [1] with fairly significant reorganization
> and a re-implementation of the processing algorithm [2], based on my
> Ruby implementation [3]. I also began changing some of the early
> examples to use more terms than CURIEs, based on some of Brian
> Peterson's comments.

Great! Thanks a bunch for doing all of that work, Gregg! I've only had a
chance to skim it so far, but I like the direction. Haven't been able to
review the processing algorithm yet.

>     * It's perfectly valid to parse JSON-LD to get a representation
>       other than RDF, or to just use it as basic JSON. This could be
>       made clearer, with the generation of RDF triples being an
>       'advanced' function.

Agreed.

>     * IRI Processing merges together the "term" and "CURIE" concepts.
>       basically, both are defined the same way in @context. In use, if a
>       mapping is found for a property key, it is a term. If the key is
>       of the form "prefix:suffix", and "prefix" is mapped within a
>       context, it is treated as a CURIE. Note that a prefix may be
>       empty, so that ":foo" is a reasonable CURIE value for expansion to
>       an IRI. This might do away with the need for @vocab.

I agree with the concept of how the IRI Processing section is written.
Typically this is seen as bad form because the RDFa spec and the CURIE
spec already specify how to do IRI processing. We don't want two specs
stating roughly the same thing. One option would be to change the
IRI/CURIE processing section in the RDFa spec, or re-use the
TermOrCURIEOrAbsIRI type from that spec. Another option would be to
change the RDFa spec.

I don't know if it does away with the need for @vocab. That is, @vocab
is nice because you don't have to go out to the network to retrieve a
document (@profile) and because you don't need to create a large @context.

>     * There's enough commonality between JSON-LD contexts and RDFa
>       profiles that I wonder if they can't be combined in some way. The
>       RDFa profile syntax is quite a bit different, but I can see that
>       it might be useful to have a single vocabulary document used by
>       both JSON-LD and RDFa, which could align better with MicroFormats 2.

This was argued for in the RDFa 1.1 work - that RDFa Processors should
read in JSON documents for their profiles. Unfortunately, JSON-LD didn't
exist at the time and so the Working Group felt that requiring RDFa
Processors to also understand how to parse JSON was too steep of an
implementation requirement. The decision was made to ensure that the
same processor could be used for both reading RDFa profiles and reading
regular RDFa documents.

A script that reads in an RDFa profile and generates a JSON-LD context
would be fairly trivial to write. The script could be triggered
depending on the requested Content-Type.

>     * We could add an @language property to set the default language to
>       apply to untyped property values.

We can already specify a language property using the following notation:

  "prop" : { "@literal": "foo", "@language": "en" }

I realize that it would be /nice/ to have a @language property in
@context or on the object, but I fear that it may be abused from time to
time and it doesn't really allow us to do much more. It's good for
convenience - don't know if it is necessary. Another way to look at
this: What's the use case that cannot be accomplished at the moment
without this feature? How many APIs end up actually specifying the
language of the text?

>     * I saw some confusion about using "@" or "@subject". Perhaps
>       @subject can be an alias for @.

Aliases seem like they may cause more confusion than help, IMHO. I think
that we should think about changing "@" to "@subject". At one point it
was "@about" to match up with RDFa... but I don't think it's really
necessary to do that. I agree with another e-mail comment you had in a
separate thread - we should probably stay away from using "@iri" to
specify the subject.

>     * There was a suggestion to change "a" to "@type". Note that both
>       are really just semantic sugar for "rdf:type". Personally, I think
>       that "@type" is better than "a", which really comes from N3/Turtle.

Agreed.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Developer Tools and Demo Released
http://digitalbazaar.com/2011/05/05/payswarm-sandbox/

Received on Saturday, 18 June 2011 18:25:02 UTC