- From: Alexandre Passant <alex@seevl.net>
- Date: Mon, 29 Aug 2011 15:22:33 +0200
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Gregg Kellogg <gregg@kellogg-assoc.com>, "public-linked-json@w3.org" <public-linked-json@w3.org>
Hi, On Mon, Aug 29, 2011 at 3:51 AM, Manu Sporny <msporny@digitalbazaar.com> wrote: > On 08/25/2011 02:11 PM, Alexandre Passant wrote: >>> >>> Be it "@": [] or "@subject": [], much of these forms fall out of >>> the general processing rules, such that every call to process an >>> entity return a value that can be used as a subject. Otherwise, we >>> end up adding special cases, where.none are necessary. >> >> It was probably not clear - I'm not asking to add special cases, but >> just found confusing the use of @ / @subject where it does not >> define the subject of a triple. But that eventually works fine with >> overloading (that's how we've done it in [1] with the use of @data) > > I know this might hurt a few brains, so apologies in advance... but we had > considered this at one point for JSON-LD: > > "@subject": ["#foo", "#bar", "#baz"], > "dc:creator": "http://example.com/people/bob" > > which would generate the following triples: > > <#foo> dc:creator <http://example.com/people/bob> . > <#bar> dc:creator <http://example.com/people/bob> . > <#baz> dc:creator <http://example.com/people/bob> . > > That's not in the spec right now and we probably won't put it in the 1.0 > spec, but have reserved the pattern if people might find it useful in the > future. > > What we were really going for with "@subject" being a non-IRI value was > supporting graph literals, like so: > > { > "@subject": { "foaf:name": "John Doe", "foaf:age": 34 }, > "dc:created": "2011-08-28" > } > > This would generate the following graph, which includes a graph literal: > > _:g1 { > _:bnode1 foaf:name "John Doe" . > _:bnode1 foaf:age 34 . > } > _:g1 dc:created "2011-08-28" . > >>> The second form should be allowed, but as you point out, the first >>> form my be required to add an @context. >> >> It is probably good to add a warning in the spec. Something like >> "Warning: This alternative serialisation does not allow to specify a >> particular @context in the data file". > > Where would you expect this warning to go in the spec, Alexandre? Ideally in section A.1 Disjoint Graphs, after the second example (that is using that serialisation) Alex. > > -- manu > > -- > Manu Sporny (skype: msporny, twitter: manusporny) > Founder/CEO - Digital Bazaar, Inc. > blog: Building a Better World with Web Payments > http://manu.sporny.org/2011/better-world/ > -- Dr. Alexandre Passant - @terraces Founder, CEO - seevl.net - @seevl Reinventing Music Discovery
Received on Monday, 29 August 2011 13:23:11 UTC