- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 06 Apr 2011 20:37:27 -0400
- To: RDF Working Group <public-rdf-wg@w3.org>
On 04/06/2011 05:12 AM, Ivan Herman wrote: > 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. I do not believe that is a good approach either. That is not to say that it is not a neat idea, but one that requires people to create vocabulary documents - which is asking too much of developers, imho. In other words: Don't make me think! This approach was left out of the latest proposal for that very reason. > 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... +1 > I see that Manu has added a @context below which may go into this > direction. Yes, that is the reason that @context was introduced. > Another approach would be to allow predicates to be either simple > terms or full URI-s. I only proposed simple terms because that is what JSON developers are familiar with these days. Having full URIs would be useful as well, imho, but that's a discussion that we can have later - by logging an issue against this proposal (support full IRIs as keys in addition to terms). The latest proposal is attempting to state: This is what JSON developers are familiar with today: * simple terms as object keys * no microsyntaxes * URLs, text and numbers as values * nested data structures The only addition is: * Add the minimum required to the above in order to extract RDF triples As Andy has already queried about - this is for the non-API use case, where it is not guaranteed that you have an RDF/JSON API to map a set of triples into a JSON object. That is, all that is available to the developer is JSON.parse(). -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: The PaySwarm Vocabulary http://digitalbazaar.com/2011/03/31/payswarm-vocab/
Received on Thursday, 7 April 2011 00:37:51 UTC