- From: Gregg Kellogg <gregg@kellogg-assoc.com>
- Date: Sat, 12 Nov 2011 17:08:20 -0500
- To: Toby Inkster <tai@g5n.co.uk>
- CC: "semantic-web@w3.org Mailing-List" <semantic-web@w3.org>, "public-rdf-comments@w3.org" <public-rdf-comments@w3.org>
Gregg On Nov 12, 2011, at 1:29 PM, Toby Inkster wrote: > On Sat, 12 Nov 2011 13:40:57 -0500 > Gregg Kellogg <gregg@kellogg-assoc.com> wrote: > >> I could serialize this to JSON-LD using consistent identifiers and >> ordering the data in a way that makes sense for my application: >> >> { >> "@context": "http://example.com/context", >> "@subject": "", >> "maker": [ >> { >> "@type": "Person", >> "homepage": "http://greggkellogg.net/", >> "name": "Gregg Kellogg" >> }, >> { >> "@type": "Person", >> "homepage": "http://tobyinsker.co.uk/", >> "name": "Toby Insker" >> } >> ] >> } > > But you could equally serialise it like this: > > { > "@context": "http://example.com/context", > "@subject": "", > "maker": [ > { > "@type": "Person", > "homepage": "http://greggkellogg.net/", > "name": "Gregg Kellogg" > }, > { > "@about": "http://tobyinkster.co.uk/#i", > "@type": "Person", > "name": "Toby Inkster" > }, > { > "@about": "http://tobyinkster.co.uk/#i", > "homepage": "http://tobyinkster.co.uk/", > } > ] > } > > ... which I believe represents the exact same triples. And then your > function: > >> function nameForHomePage(homepage, data) { >> return $.grep(data["maker"], function(person, ndx) { >> return ( person["name"] && person["homepage"] ) ; >> }).shift; >> }; > > ... no longer works on the input. i.e. the function doesn't operate on > JSON-LD, but on a highly constrained subset of JSON-LD. This is why the results should be framed using a framing document, to ensure that results are returned as expected. Alternatively, results could be returned in normalized form, which would also yield a similar predictable representation, but would be more verbose and require the use of full IRIs instead of simple tokens for property names. Framing works by first expanding (or normalizing) the document, and then applying a separate specification to construct the output. A framing document, for this case, might look like the following: { "@context": { "Person": "http://xmlns.com/foaf/0.1/Person", "homepage": "http://xmlns.com/foaf/0.1/homepage", "maker": "http://xmlns.com/foaf/0.1/maker", "name": "http://xmlns.com/foaf/0.1/name" }, "maker": [{ "@type": "Person" }] } This ensures that the application receives the data in the way that is most easily processed. For an application that has a specific purpose for accessing the data, this ensure that it is put in the best format for the processing (sort of a JSON-QL, if you will). You can try it out at http://json-ld.org/playground/, or with the complete example at http://bit.ly/uKPbGs (select Framed) to see the framed results. > If I were serving up data in JSON-LD, and decided I had some extra > information to publish, how can I add it to my JSON output without > risking breaking some of the consumers? The idea would be that when the data is requested, the server performs framing when delivering the data. Alternatively, you can get the data back in any JSON-LD format and apply framing on the client, as Manu has a complete JavaScript implementation of JSON-LD, including framing. Of course, the frame may remove extraneous information you publish, but by definition, this isn't important for the particular application accessing it. If you don't want to do framing, you can always get data back in normalized format, which is entirely predictable, and could use pretty much the same access code, but with full IRIs and a certain amount of access to sub-objects. Gregg > Try typing this at a Linux command line (assuming bash): > > URL=http://danbri.org/ > curl -Ls $URL"/foaf.rdf" |\ > grep foaf:name |\ > head -n1 |\ > sed -r 's/^.*>(.*)<.*/\1/' > > It works with http://mmt.me.uk/ too, and http://people.w3.org/amy/. But > as a generalised homepage-to-name function it leaves a lot to be > desired. If consumers start relying on that sort of function, then it > rather constrains the kinds of updates Dan can make to his FOAF file. > > -- > Toby A Inkster > <mailto:mail@tobyinkster.co.uk> > <http://tobyinkster.co.uk>
Received on Saturday, 12 November 2011 22:09:07 UTC