- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 30 Dec 2011 13:49:28 -0500
- To: public-xg-webid@w3.org
- Message-ID: <4EFE07B8.4000203@openlinksw.com>
On 12/30/11 4:14 AM, Mo McRoberts wrote: > On 30 Dec 2011, at 06:59, Peter Williams wrote: > >> I think I have just learned (and im leaping here) that there is just like in C++ a magic #fragment name called "this". I dont have a literal in my stream named #this, though - any more than I have such a literal in C++ structure. OK. Wonderful. That makes sense (by analogy with C++). I now have a way to always name what is otherwise an address (causing endless fuss). > No; #this isn’t magic — indeed, having a fragment at all isn't magic (you can claim to be a resource if you really want to, but you usually don’t want to). What you pick as your fragment (to differentiate things from resources) doesn’t matter, so long as you’re consistent about it for that thing. > > > I’m a tad confused — I guess I’ve missed a message somewhere — looking at: > > http://yorkporc2.blogspot.com/ > > …you’re consistent about using<http://yorkporc2.blogspot.com/#me> as your identifier. > > Looking at: > > http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1 > > I’m not seeing any incidence of 'this' in the N3 — it’s exactly as in the RDFa: > > @prefix ns1:<http://yorkporc2.blogspot.com/#> . > > ns1:me a foaf:Person; ... > > …which expands to: > > <http://yorkpc2.blogspot.com#me> a foaf:Person ; ... > > I can't see why you'd want to use '#this' with either of those resources. > > M. > Mo, Goal: To leverage a specific RDF translator (RDFizer) to make a descriptor resource for a subject unambiguously named using a de-referencable HTTP URI. Rule: The name MUST resolve to a descriptor resource. Here's the breakdown: 1. http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1 -- the address of a descriptor document (a resource) that describes a name subject 2. the named subject, as per graph borne by the descriptor resource: <http://yorkporc2.blogspot.com/#me> . Problem: Where is the relation that closes the loop re. resource at: http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1 ? We need the following to work re. Linked Data URIs: 1. reflection from the inside out -- the descriptor resource (directed graph) exposes the de-referencable URI of its subject 2. de-reference from the outside in -- de-referencable URI resolves descriptor resource (direct graph) Solution: 1. Mint a de-referencable URI by levering implicit indirection delivered by # based URIs 2. Add an owl:sameAs relation to the graph -- this is the tricky part since this should really be part of the translator . Hence: <http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1#this> . Usage example: that can go into the SAN slot of an X.509 certificate and courtesy of owl:sameAs relation still result in successful validation albeit subject to the OWL reasoning capabilities of the verifier. The other option for Peter is that he can have both URI in SAN i.e. 1. http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1#this 2. http://yorkporc2.blogspot.com/#me . The verifier honors the fact that both URIs are in a signed co-reference relation. Thus, whichever resolves to a graph where one of the URIs is in a relation with the Certs. Public Key also suffices. Modulo a bug in our own verifier, I expect the above to work. -- 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Friday, 30 December 2011 18:49:51 UTC