Re: Another Translator for RDF

Another great post.

A goal of webid was (and this always falls by the wayside in such groups) User centricity - freedom from overbearing vendors (think wiki leaks vs PayPal). Think of Dnssec, controlling authority resolution (and delivering the perfect off switch).

I thus wanted multiple copies, in different jurisdictions. Shut down one, there are m more, and easy to make yet more.

Now, the need for that (in my personal social structures) is small (if not zero). But it's a great forcing function to analyze failure modes and dependencies. Done right, this translates into open markets (like ca) and a new service market exists (employing folks).

It may if may not help liberate folks from colonialism (or the proxy dictator) but that's not my concern (I did my bit for the cause in Che land (Bolivia)).

Sent from my iPhonenk 

On Dec 30, 2011, at 4:48 PM, "Mo McRoberts" <mo.mcroberts@bbc.co.uk> wrote:

> 
> On 30 Dec 2011, at 18:57, Kingsley Idehen wrote:
> 
>> On 12/30/11 6:48 AM, Mo McRoberts wrote:
>>> It's a neat trick, but I can think of a couple of awkward reasons why you might not want to rely on the behaviour. Tends to be easier to use the translator to generate the format you want and the republish it with conneg switched on!
>> 
>> Trouble is that you have to control the server to do content negotiation and explicit de-reference etc.. When you have # URIs you can leverage implicit de-reference
> 
> I’m not saying “don't do fragments”!
> 
> What Peter was publishing — as RDFa — was perfectly fine. The difficulty arises when you want to publish an equivalent set of triples somewhere *else* (specifically) in a different format but still referring to the original URI you picked for yourself — i.e., sticking the automated translation in the middle of the chain, without having it made available at the original URI.
> 
> The tricksy part is that you have a SAN extension which asserts that you are known as
> 
> URI-A, URI-B
> 
> Consumer requests URI-A and discovers that it can't parse what it retrieves, so moves on to URI-B
> 
> It *can* parse the document from URI-B (because it's been auto-translated into a form it can process), and finds that the only assertion in that document about URI-B is an owl:sameAs relation referring it to URI-A.
> 
> Now, because URI-A's document can't be parsed, there's no way to verify that it does contain the triples which confirm the relationship between it as a WebID URI and the WebID certificate, *however* a consumer can look for triples describing URI-A in the document referring to it retrieved from URI-B: in this case, it finds some, and can process them as being equivalent to as if they were asserted about URI-B, but what it cannot do is state that URI-A is an identifier for the certificate-holder.
> 
> This is all fine, but it's behaviour which has to be defined somewhere if it's desirable — some consumers might do it, others might not — following owl:sameAs (and whether to follow them to other documents, and how to behave if retrieval of those fails or has already failed) isn't prescribed at present.
> 
> Thus, while multiple SAN URIs *do* work as a synonym mechanism (provided the consumer can retrieve and process data from each of the synonymous URIs), owl:sameAs won't necessarily.
> 
>> Peter, is basically, attempting the very same things for WebID that Martin Hepp achieved with GoodRelations. Showcase how its all works in the very simplest form possible (at InterWeb scale) modulo any biases re. platforms and best practices.
> 
> Well, no, the simplest form possible is just publishing the RDFa (or any other single serialisation) and letting the consumers process that, surely? :)
> 
> M.
> 
> -- 
> Mo McRoberts - Technical Lead - The Space,
> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
> Project Office: Room 7083, BBC Television Centre, London W12 7RJ
> 
> 
> 
>

Received on Saturday, 31 December 2011 01:01:32 UTC