Re: [JSON] A starting point...

I need a clarification on Nathan's original email. He writes:

[[[
when terms from multiple vocabularies are needed it requires people 
to make their own custom vocab which includes aliases to terms in other 
vocabularies. (having a single cachable vocab is lighter for network 
though and easier to maintain)
]]]

the way I read this is that, if I use, say, dc and foaf in the same data, and I decide to use foaf, then I will have to set up, somewhere on the Web, a separate vocabulary file that defines the dc terms and, I presume, would include a bunch of owl:samePropertyAs to the 'real' ones. While this is, theoretically, a working solution, this means that RDF/JSON environments will have to understand at least this owl term and work their way through it, which is an extra load that no other serializations have. I do not believe this is really a good idea.

Besides: a major advantage of RDF over other formats is the possibility to mix terms from various vocabularies easily. This is the main advantage of, say, RDFa over microformats or even microdata; loosing this for RDF/JSON seems to go in a direction that makes RDF loose its advantage over other data formats...

I see that Manu has added a @context below which may go into this direction.

Another approach would be to allow predicates to be either simple terms or full URI-s.

Ivan

On Apr 6, 2011, at 02:50 , Manu Sporny wrote:

> I really liked Nathan's proposal a few weeks ago:
> 
> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Mar/0565.html
> 
> Tom's serialization work is also excellent, and is a must read before
> diving any further into this e-mail:
> 
> http://www.w3.org/2011/rdf-wg/wiki/JSON-Serialization-Examples
> 
> I'd like to see if we can come to some sort of consensus on a starting
> point based on Nathan's proposal. I'm going to remove things that raised
> issues w/ some people and see if we can all agree if the result could be
> the starting point for the JSON work.
> 
> Note that this proposal is imperfect by design - it is only here to
> capture the things that the majority of the group seem to agree upon.
> It's merely meant to put a stake in the ground so that we may start
> building on top of it. If we can get agreement on these 5 principles,
> then we can add on features as the group discusses them:
> 
> 1: Constrain JSON [1] to be an (optionally nested) sequence of one or
>   more objects (where one, no enclosing [] is needed).
> 
> 2: constrain object keys to be strings with no white space.
> 
> 3: add recognition for a special "@id" property who's value is an IRI
>   (sets the subject of the object when present).
> 
> 4: add recognition for a special "@type" property who's value is a
>   simple string. The value is looked up in the @context.
> 
> 5: Support a "@context" property that allows for a set of mappings from
>   JSON keys to IRIs.
> 
> {
>  "@context":
>  {
>     "Person": "http://xmlns.com/0.1/foaf/Person",
>     "name": "http://xmlns.com/0.1/foaf/name",
>  },
>  "@id": "http://jondoe.example.org/#me",
>  "@type": "Person",
>  "name": "Nathan Rixham"
> }
> 
> That's it - please +1 below each number if you support the general
> direction of the feature. -1 if you don't, please explain if you don't.
> It's been around 2 weeks, so hopefully some of us have had time to let
> these ideas kick around in our heads for a while. I'll try to setup a
> Doodle poll to have a discussion about this proposal later on in the
> week as well as discuss some of the serialization work that Tom has done.
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: The PaySwarm Vocabulary
> http://digitalbazaar.com/2011/03/31/payswarm-vocab/
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf