W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2011

Re: [JSON] PROPOSAL: Syntax structure should be object-based

From: Yves Raimond <Yves.Raimond@bbc.co.uk>
Date: Thu, 17 Mar 2011 10:23:54 +0000
To: Andy Seaborne <andy.seaborne@epimorphics.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>, RDF Working Group <public-rdf-wg@w3.org>
Message-ID: <20110317102338.GA20131@dvbstreamer.national.core.bbc.co.uk>
On Thu, Mar 17, 2011 at 08:50:49AM +0000, Andy Seaborne wrote:
> >>Sometimes it sounds more like "GRDDL for JSON".  The mapping isn't
> >>universal - the generation of IRIs from data that has sufficiently
> >>unique keys is application dependent, for example.
> >
> >Yes, the mapping can't be universal. However, not because the unique
> >keys are application dependent (you can always specify a default
> >vocabulary to map each unknown unique key to... you could even say that
> >you could use bnodes as predicates here). In RDFa, these unique keys can
> >be given a prefix via @vocab... RDF in JSON could have the same
> >mechanism that basically states: "If you can't find a mapping for a key,
> >append it to this URI." For example:
> >
> >{
> >    "#": { "@vocab": "http://example.org/foo#" },
> >    "sparqly": "Andy Seaborne",
> >}
> >
> >The above would create the following triple:
> >
> >_:bnode1<http://example.org/foo#sparqly>  "Andy Seaborne" .
> 
> That was not the point of my example.  The keys here are in the
> sense of database keys.  Subjects and objects need URIs for linking.
> 
> If we have:
> 
> {
>   "employeeId":   "1234" ,
>   "name"      :   "Alice"
> }
> 
> and want the URI to be <http://company.com/employee/1234> then the
> "http://company.com/employee/" has to come from somewhere as does
> the rule for concatenation.
> 
> Maybe that happens by something "#" part
> 
> { "#" : { "@gen": "http://company.com/employee/${name}", .. }

Or rather { "#" : { "@gen": "http://company.com/employee/${employeeId}", .. }

Anyway, a definite +1!

y

> 
> 	Andy
> 
Received on Thursday, 17 March 2011 10:24:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:04 UTC