Re: JSON-LD Spec confusion

On May 18, 2011, at 9:23 PM, Manu Sporny wrote:

On 05/16/2011 04:10 AM, Gregg Kellogg wrote:
...
@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.

Another alternative would be to use default prefixes for @vocab, which would be something like the default prefix definition in N3. In that case, the default prefix is bound to <#> unless it's specified. The rule could be to always use @base to expand strings that are not CURIEs, and either have @vocab define the default prefix, or use an empty-string mapping. For example:

{
"@context": {
"@vocab": "http://example.org/default-vocab#",
"@base": "http://example.org/baseurl/",
"@coerce": { "xsd:anyURI": ":foo" }
},
"@": "",
":foo" "bar"
}

This could expand to <http://example.org/baseurl/> <http://example.org/default-vocab#foo> < http://example.org/baseurl/bar>

@vocab could be considered as syntactic sugar for the empty string, being the default prefix mapping. This also gets around the different arithmetic requirements for @vocab and @base.


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.

I have a separate post that might serve as a manifesto for an alternative to RDF.

...

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


[1]: http://smiy.sourceforge.net/olo/spec/orderedlistontology.html