Re: JSON-LD Spec confusion

Sorry it took so long to get back to you Gregg. Been slammed with some
JSON-LD related stuff - we're currently going through a
re-implementation based on the new spec.

On 05/09/2011 07:29 PM, Gregg Kellogg wrote:
> Hi, I've implemented a Ruby version of JSON-LD [1] and [2], and going
> through the spec I have some questions:

Fantastic!

> In processing step 2.1 for @context processing. The text indicates to
> merge each key-value pair into the active context. Is any processing
> performed on the values. For instance, could a value be a CURIE, or
> {"@iri": <value>}? Examples indicate that there is no such
> processing, and each value should be an absolute IRI. The wording
> makes this unclear.

We were discussing this over the past weekend. The current thinking is
that no processing should occur on the actual values. We were even
thinking of going as far as requiring all values in @coerce to be CURIEs.

So, based on the current thinking, @iri would not be allowed.

What a processor does internally is, of course, up to the processor. At
some point, the values will have to be expanded out to full IRIs in
order to do the proper equality comparison.

We had thought at one point of requiring full IRIs, but note that this
list of types to coerce may get very large over time and thus the
default context would become unwieldy. In order to combat this, we
thought that CURIEs might help us to keep the list smaller than if we
were to use full IRIs.

> Also in 2.1, for @coerce the doc says to merge each key-value mapping
> to the local context's @coerce mapping, overwriting duplicate values.
> In the case where a mapping is indicated to a list of properties
> (e.g., { "xsd:anyURI": ["foaf:homepage", "foaf:member"] }, does this
> overwrite a previous mapping of { "xsd:anyURI": "foaf:knows" }, or
> add to it. I've implemented it as being additive with replacements.

You did the right thing - it's supposed to be additive with replacements.

> For value coercion, does the lookup happen on the lexical- or
> value-space of the property? For example, if a context defines "f":
> "http://xmlns.com/foaf/0.1/" is "f:age" coerced to xsd:integer?

Yes, the "f:age" object is coerced to "xsd:integer" if a mapping exists
from "f" to "http://xmlns.com/foaf/0.1/" in the current context.

> The
> default context currently coerces "foaf:age" to "xsd:integer". I
> presume the value-space is used for comparisons, so the mapping is
> based on an expanded URI, not the CURIE lexical value.

Yes, you are correct. All comparisons should be performed in value-space.

> In 5.1 IRIs, the arithmetic requirements aren't laid out. I presume
> that for @vocab and CURIE expansion, it is treated as a string
> concatenation, for @base, it is treated like URI join (i.e., "@base":
> "http://example.com/foo", "@": "bar" results in
> <http://example.com/bar> not <http://eample.com/foobar>.

Hmm... good question - hadn't put enough thought into that one.

I think expanding that to "http://example.com/bar" would confuse the
least number of people.

However, it may be that "http://eample.com/foobar" is easier to
implement and more correct.

We were also considering removing @base entirely as we couldn't think of
a good use case for it. <BASE> makes sense in HTML, but we don't know if
it makes sense in a Web Services framework. That is, do we want to
publish data with relative URLs? Why would someone want to do that?

@base is in there because we thought people might complain if it wasn't
in there... but do we really need it?

> -- For my parser, I found it useful to automatically coerce rdf:type
> to xsd:anyURI, as "a" is semantic sugar for "rdf:type".

Good point, I'll make sure to put that in the next version of the spec.
The Default Context type coercion list is woefully minimal. I just
slapped it together to give an example of what the final product would
look like. I think you're right, rdf:type should be in the @coerce list
for xsd:anyURI.

> Regarding RDF List creation in 3.3, I found it to be simple enough,
> as the logic is pretty much the same as for Turtle. I think it's
> important that JSON allow for an RDF expression of ordered elements,
> and like it or not, the RDF List mechanism is the only viable one we
> have.

Maybe we can succeed with lists in JSON-LD, where we failed in RDFa. :)

Or, maybe we can create a better list mechanism and feed that work into
the RDF WG? That may be going a bit too far?

> In 6.2 Type Coercion introduces @type, should this not be @coerce?
> The semantics are equivalent. It's also in an example in 8.3.3.

That's wrong, it's been fixed.

Thanks for the feedback Gregg, much appreciated! We'll have our
C++-based JSON-LD parser out shortly.

How long did it take you to put a first-cut of the JSON-LD parser together?

-- 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 Monday, 16 May 2011 04:04:46 UTC