Re: JSON-LD Spec confusion

On May 16, 2011, at 5:04, "Manu Sporny" <msporny@digitalbazaar.com> wrote:

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

It seems reasonable to me to use URIs for ,aping and URIs or CURIEs for @coerce. Note that in RDFa profiles, mappings are literals, not URIs (although in the anyURI value apace. Does the same reasoning not apply?

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

I think @base is a good idea. It can help reduce document size, and makes things more readable.

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

I think it's a bad idea when serializations start creating their own semantics. Like it or not, that's the provenance of the RDF WG.

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

It was pretty easy, did it in just a couple of days, taking advantage of Ruby's JSON support and structural components from my other parsers.. Serialization should be a breeze, although normalization may be hard for versions of Ruby not supporting ordered hashes.

> -- 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 08:10:57 UTC