W3C home > Mailing lists > Public > public-xg-webid@w3.org > January 2012

RE: Another Translator for RDF

From: Peter Williams <home_pw@msn.com>
Date: Sun, 1 Jan 2012 10:45:05 -0800
Message-ID: <SNT143-W251612D20F95A49AD6BF8592900@phx.gbl>
To: <mo.mcroberts@bbc.co.uk>, <kidehen@openlinksw.com>
CC: "public-xg-webid@w3.org" <public-xg-webid@w3.org>

Again, either the "great leap forward" of semantic web technologies will address this, or webid will not have done anything not already done 15 times before with alternative methods. Since its all about temporary sources of authority making statements "about" you, my gut tells me that the semantic does something original, when 2 sources of "about" authority can be regarded as equivalent. Lets get less abstract. If uriburner, as an about authority on my blogspot URI/document, caches the document, its proxy URI can go in my cert alongside that of blogspot. Blogspot can suspend me tomorrow, but uriburner continues to offer support. Not only does it have cached copy of yorkporcs triples, but its up to uribuirner to decide when (and if ever) they are no longer "accurate". It can ignore the cache control response headers, should it wish.  Furthermore, if my own instance of ODS (pw-uriburner) does the same, there are now twou sources of "about authority". Perhaps I will write another card, with the same modululs, not hosted blogspot (with whom I falled out), which makes owl:sameAs references to the 2 caches at uriburder and pw-uriburner (but not to blogspot, from which tehse two *initially* crawled triples). one class of webid validator may be cued to say: if there are 2 references to two caches (about some anonymous blog site, that dumped me yesterday), this is the criteria WE deem to satisfy OUR validity criteria. Our authn guard lets such a user (e.g. wikileaks) in (even though PayPal and Visa banned wikileaks). If webid can do this, semantic web has done something (not present, in practice).  From what I can tell, its was THIS KIND of culture that Henry and co (including TBL) were seeking. It was reactionary (in a useful manner). Now, its not original work nor original analysis, and I should make patent disclosures, here. This UNDERLYING  topic area FOR CERTS was the subject of considerable investement (in a failed silicon valley dotcom business), but folks still own the IP assets (and the patents). They were written pretty generally.   
 > From: mo.mcroberts@bbc.co.uk
> Date: Sun, 1 Jan 2012 16:38:56 +0000
> CC: public-xg-webid@w3.org
> To: kidehen@openlinksw.com
> Subject: Re: Another Translator for RDF
> On 31 Dec 2011, at 17:52, Kingsley Idehen wrote:
> >> 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.
> The problem here isn't the data. Getting the union set of triples is fine. The problem here is what you consider the URI to be for the certificate holder. As you can't retrieve and process the data for URI-A, you can't treat that URI as belonging to the holder.
> It's a subtle point, but it's an important one when you're dealing with synonyms.
> 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 Sunday, 1 January 2012 18:45:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:54 UTC