Re: RDFa without using xmlns:

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