W3C home > Mailing lists > Public > public-linked-json@w3.org > May 2011

Re: JSON-LD Spec confusion

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thu, 19 May 2011 00:23:00 -0400
Message-ID: <4DD49B24.4080609@digitalbazaar.com>
To: "public-linked-json@w3.org" <public-linked-json@w3.org>
On 05/16/2011 04:10 AM, Gregg Kellogg wrote:
>> 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 mapping 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?

Mappings should be plain literals - yes. At least, they are in my mind -
let me clarify.

When I was saying "URI" or "CURIE" - I was speaking about the lexical
space, not the value space. To put it another way, in @coerce, we were
thinking about something like this:

WRONG: "xsd:anyURI": "http://xmlns.com/foaf/0.1/homepage" WRONG
WRONG: "http://www.w3.org/2001/XMLSchema#anyURI": "foaf:homepage"
CORRECT: "xsd:anyURI": "foaf:homepage"

So, basically, if you wanted to coerce anything, you should be using
CURIEs. There were two reasons for this: 1) Simplifying the
implementation of the processor, 2) reducing the potential size of the
Default Context.

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

Ok, so we'll keep it in there for now. The trade-off is design
complexity. Also note that @base only applies to things on the
right-most side of a JSON statement:

 "LEFT": "RIGHT"

@base only applies to RIGHT.

In order to affect LEFT, you have to use @vocab. This was confusing to a
few of the folks in our company. They were wondering why @base didn't
apply to both the left and the right side.

I'm only bringing this up because while @base may make sense to people
that think deeply about this stuff - people that just want it to use it
and it work have to remember some of these more esoteric rules.

So, supporting base adds complexity to authors and to implementers - are
the gains in document size reduction and readability worth it in the
end? I'm just barely on the side of "it's not worth it to have @base or
@vocab".

However, I know Nathan really wants @vocab... and you seem to support
having @base in there. My opinion is that if we rip one of them out of
there, we should rip the other one out.

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

Maybe. There are some that really don't like RDF and see JSON-LD as a
way of getting away from RDF. If those people don't care about RDF list
semantics, they would adopt whatever list semantics were provided in
JSON-LD.

I'm not saying that this is a good thing - just outlining it as not
mattering to people that don't care about RDF.

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

That's good to hear. It's amazing how much support for ordered hashes
helps the normalization stage for JSON-LD. Python has a nice ordered
hash serializer for JSON.

-- 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 Thursday, 19 May 2011 04:23:27 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:34 GMT