Re: Another Translator for RDF

On 12/30/11 7:47 PM, Mo McRoberts 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.

Identifier equivalence has been asserted in a signed claim via the use 
of multiple URIs in a Certs. SAN. The effect here is that we have 
synonyms so the public key associated with URI-B is now also a relation 
with URI-A. The fact that we can't make a union of all the data the one 
could de-reference via URI-A and URI-B doesn't matter re. this kind of 
equivalence and the resulting assurance.

What's up for question, and certainly needs a note at the very least,  
is this question: what should verifiers do re. co-reference claims? We 
have different kinds taking shape:

1. certificate hosted, solely -- here we just have multiple URIs in SAN, 
but no matching claims in Idp space
2. idp space hosted, solely -- here we have the co-reference claims in 
the form of owl:sameAs relations in idp space
3. mirrored co-reference claims, but cert. signed only - the certificate 
has a signed claim, the idp has an owl:sameAs but the idp space claim 
isn't signed i.e., the triple isn't signed (you do this via terms from 
an reification ontology/vocabulary )
4. mirrored co-reference claims -- in this case you have the cert. 
signed claim and a signed owl:sameAs relation in idp space.

There basically multiple assurance levels re. the above. Personally, I 
don't expect the WebID to mandate handling these by any verifier, but 
the spec must at least shed light on these matters especially as this is 
a coherent segue into the inescapable realm of OWL enhanced relation 
semantics.

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

Yes.

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

As per earlier comment. Being a synonym doesn't mean you have 
equivalence by values (data graph). It means you have equivalence by 
name based co-reference. Also remember, URI-A and URI-B can be 
associated with a Public Key in IdP space via a predicate (e.g. 
cert:key) if said predicate is declared in it ontology to be an 
owl:InverseFunctionalProperty (IFP) . In this case URI-A and URI-B are 
synonyms by virtue of a common values (the Public Key) in their public 
key relations.

You can make an IFP claim in idp space etc..

Anyway, you, Peter, and I are indicating, these matters need some 
attention in the spec. Not as MUST items, but as important FYIs in a 
sense. We want the WebID spec to be ready for users/developers 
transitioning basic curiosity to serious implementation and exploitation.

>
>> 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? :)

No, neither XHTML+RDFa nor HTML+RDFa are accepted as being simple by 
publishers that fit into the "end-user" profile. Methinks, the safest 
bets are:  HTML+Microdata and HTML+RDFa for end-users. Then 
HTML+Microdata, HTML+RDFa, and Turtle for developers.
>
> M.
>


-- 

Regards,

Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen