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