W3C home > Mailing lists > Public > public-xg-webid@w3.org > December 2011

Re: Another Translator for RDF

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Fri, 30 Dec 2011 13:49:28 -0500
Message-ID: <4EFE07B8.4000203@openlinksw.com>
To: public-xg-webid@w3.org
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








Received on Friday, 30 December 2011 18:49:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 30 December 2011 18:49:51 GMT