- From: Martin McEvoy <martin@weborganics.co.uk>
- Date: Tue, 08 Dec 2009 11:15:52 +0000
- To: Toby Inkster <tai@g5n.co.uk>
- CC: Mark Birbeck <mark.birbeck@webbackplane.com>, RDFa <public-rdf-in-xhtml-tf@w3.org>
Toby Inkster wrote: > Replying to several messages in one... > > On Mon, 2009-12-07 at 23:07 +0000, Martin McEvoy wrote: > >> sorry about the quotes on everything php json decoding wont work with >> out them. >> > > PHP's JSON implementation is perfectly correct to reject input where > strings have not been quoted. RFC 4627 specifies that all strings in > JSON *must* be quoted: > > string = quotation-mark *char quotation-mark > > (quotation-mark is a double-quote). > I agree ;) > Mark Birbeck wrote: > >> First, the problem with using link/@rel value to point to a set of >> prefix mappings is that you won't find them until you start >> parsing...and by then it's too late. >> > > I disagree. I think it's an elegant way of linking to the mappings > without defining much new stuff. (No new elements or attributes.) It is > no more a problem for sequential programming than processing <base href> > is, and RDFa processors already need to do that. Diving into the DOM to > pick up prefix mappings before processing the root element for RDFa > should be no more of a problem than diving in to pick up the base URI > is. > > >> One possible solution would be to use another attribute. Myself I'd >> like to see us use @profile, and if the receiving server were to use >> content-negotiation, then the prefix mappings could come back in any >> form. >> > > I think using @profile would be a waste of bandwidth. It's already used > for GRDDL and XMDP profiles. An RDFa processor would probably end up > downloading a bunch of files that it doesn't have anything useful it can > do with. > > >> http://code.google.com/p/backplanejs/wiki/Rdfj >> > > I'd recommend removing references to "JSON" from this page. The format > described does not seem to be serialisable to JSON (as defined by RFC > 4627, or by json.org), though probably a subset of RDFj could. For > example, Javascript functions may be used as literals in RDFj, but > cannot be represented in JSON. > Oh I don't know this seems to be valid json .... { "context": { "token": { "name": "http://xmlns.com/foaf/0.1/name", "homepage": "http://xmlns.com/foaf/0.1/homepage" }, "name": "Anna Wilder", "homepage": "<http://example.org/about>" } } as does this.... { "token": { "foaf": "http://xmlns.com/foaf/0.1/", "dc": "http://purl.org/dc/elements/1.1/" } } Mark mentioned that the page needs to be updated to use quotes ;) try validating the examples above here: http://www.jsonlint.com/ > Martin McEvoy wrote: > >> Another way I tried was setting a header tag to something like >> "X-Dataset: http://...dataset.json" >> It worked as a way to deliver the json to the parser before parsing >> which was easy enough for parsers to Implement... but I think it may >> be a little beyond what is actually practical... >> > > This would be useless to processors which can't see the HTTP envelope. > And if a web page were saved to disk, it would lose its headers, and > thus its semantics. Whatsmore, some publishers struggle with web server > configuration, so requiring them to send particular headers can be a big > ask. No, HTTP headers are not a good way of doing this. > I strongly Agree with you Toby, its nice to eliminate things that *definitely* wont work ;) > That said, if they were to be used, I'd recommend using the existing > Link header (currently going through the later stages of the RFC > process), rather than minting an X-Header: > > Link: </files/my_ds.json>; rel="http://weborganics.co.uk/ns/dataset" > > (rel types in Link headers are URIs) > > I like Link headers ;) .... In my Apache htaccess file I can add something like ... Header set Link: </files/my_ds.json> ;rel=http://weborganics.co.uk/ns/dataset which is easy enough for implementers. Thanks Toby -- Martin McEvoy WebOrganics http://weborganics.co.uk/ Add to address book: http://transformr.co.uk/hcard/http://weborganics.co.uk/
Received on Tuesday, 8 December 2009 11:16:23 UTC