Re: RDFa without using xmlns:

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).

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.

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.

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)

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Tuesday, 8 December 2009 09:46:39 UTC