Re: [JSON] the simple pivotal choice

On 03/11/2011 01:33 PM, Nathan wrote:
> so I guess, if we admit that prefixes are
> not registered names, and are unreliable when following your nose (that
> is you'd need to compare full URI equality, not CURIE token equality)
> why have them there at all?

This doesn't make sense to me - just because prefixes are not registered
doesn't mean they're unreliable when following your nose. Are you
stating that we'd attempt to follow our nose on "foaf" alone? I don't
think anyone has put that forward as a potential solution for
follow-your-nose. We follow our noses using full URIs, not compacted
prefixes - and that full URI is specified when we declare the prefix.

I don't think we have enough data to eliminate CURIEs at this point in
time - we would be making an arbitrary decision based on insufficient
data. Worse, we're assuming that we know that developers are not going
to find CURIEs useful in their RDF in JSON. Our company uses CURIEs all
the time in our JSON-LD, so I personally reject the notion that they're
not useful, even if the prefixes are not registered.

Also keep in mind that follow-your-nose isn't something that is on the
fore-front of many JSON developers minds. There are lots of other things
that take higher priority - such as message size. If we don't have
prefixes, we are asking developers to create a map of every single
property transmitted via RDF in JSON. If there are 24 properties that
all use the same vocabulary, that's 24 mappings in the default context
and 24 properties.

With a prefix-only solution, we'd have to setup the prefix using 1
mapping in the default context and 24 properties. That's why we chose to
use prefixes for many of our properties in PaySwarm - if we didn't use
prefixes, our message sizes (due to the default context) were gigantic
compared to the data that was being transmitted. We thought about a
system that would scan the JSON-LD leaving the system and only include
the mappings that were used, but even that was eating up more CPU
resources than we liked.

We can easily support both prefixes and terms, why would we choose one
over the other?

> This could be seen as a trade off thing, all names we use that are not
> full URIs will need to be resolved when using the JSON like it's RDF, so
> why not just keep using simple names ("name") to alias them, preserving
> the simplicity and beloved . notation?

We don't have to choose one or the other :), we can have both:

var obj = rdfInJson.parse(rdfInJsonText,
             {"http://xmlns.com/0.1/foaf/name": "name" });

print obj.name;

In fact, the above is far more powerful - it lets the developer decide
how they'd like to map the object. That's where the power should be - in
the developers hands.

> Well the way I see it, is that with JSON, people are either going to be
> using data from a single source, or following their nose around the
> interwebs. So, for a JSON serialization, I feel we should either use
> simple terms for properties, or full URIs.

I think we should give developers the choice to work how they would like
to work - terms, CURIEs or full URIs. Picking from two extremes is not a
healthy way to form consensus. :)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Towards Universal Web Commerce
http://digitalbazaar.com/2011/01/31/web-commerce/

Received on Wednesday, 16 March 2011 00:01:40 UTC