[OpenID] fragment identifiers

Story Henry henry.story at bblfish.net
Sun Aug 5 19:18:29 UTC 2007


Hi Peter,

given that you are having trouble understanding something, bear with  
me if I don't understand your misunderstanding correctly.
I'll try my best here....

On 5 Aug 2007, at 19:50, Peter Williams wrote:

> I think I now half-understand a thread of discussion that started  
> some while ago: addressing fragment-ids on OpenID URIs, in a FOAF/ 
> RDF context. The topic seemed to center on the question: how should  
> the OpenID normalization function handle URI fragments?

Ok so I am not sure what the normalization function is. Assuming you  
mean the process which takes the string entered in an OpenId box on a  
site I want to log into and turns it into a full URL. So I could  
enter openid.sun.com/bblfish and it would transform that, normalize  
it to http://openid.sun.com/bblfish

Next I am not sure how the problem of URI fragments gets involved  
here. I think you are referring to the widely accepted usage that one  
should identify non information resources with URIs ending in  
fragment identifiers in RDF.  [1] This makes it easy to find the  
information about those objects by doing a GET on the URI (http get's  
always remove the hash).

So for example I can be identified by <http://bblfish.net/people/ 
henry/card#me> but you can get information about me by doing a GET on  
http://bblfish.net/people/henry/card

Since OpenId are not necessarily foaf files the foaf community has  
create a new foaf:openid relation that relates an Agent to a  
resource . For example if you look at my foaf file in N3 using

hjs$ cwm http://bblfish.net/people/henry/card

you will get among others the following relations

@prefix ca: <#> .

  <>  a      <http://xmlns.com/foaf/0.1/PersonalProfileDocument>;
      <http://xmlns.com/foaf/0.1/maker> ca:me;
      <http://xmlns.com/foaf/0.1/primaryTopic> ca:me;
      <http://xmlns.com/foaf/0.1/title> "Henry Story's FOAF file" .


ca:me  a    <http://xmlns.com/foaf/0.1/Person>;
        <http://xmlns.com/foaf/0.1/openid> <http:// 
bblfish.videntity.org/>,
                                           <http://openid.sun.com/ 
bblfish> .

I.e. it is saying that the document is about ca:me, and that I have  
two openids.
Since foaf:openid is an inverse functional property those resources  
identify me indirectly. Ie if you find somewhere
some document say

[] foaf:openid <http://openid.sun.com/bblfish>;
    foaf:mbox <mailto:henry.story at bblfish.net> .

You will now that this refers to me, and that they are claiming that  
to be my mailbox .


CONCLUSION
----------

This means that my openid does not have to be either an identifier  
for me nor an identifier for my foaf file.
If you wish to make the openid an identifier for a foaf file then  
that works out just as above. You would have a
hash uri to identify a person, and an openid relation that would  
point to the foaf file. So imagine Sun set it up so that
http://openid.sun.com/bblfish had an RDF representation that returned  
a foaf file for me, then it would contain the following:

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix oid: <http://openid.eg/ont/#> .

<http://openid.sun.com/bblfish>
        a foaf:PersonalProfileDocument, oid:OpenIdentifier;
        <http://xmlns.com/foaf/0.1/primaryTopic> <http:// 
openid.sun.com/bblfish#me> .

<http://openid.sun.com/bblfish#me>
         a foaf:Person;
         foaf:openid <http://openid.sun.com/bblfish> .


Now if you want your openid to also be an eRdf or RDFa document, then  
you would just need to write the above out in the standard way in  
that document.


[1] there is a pretty long discussion here
     http://www.w3.org/DesignIssues/HTTP-URI
[2] http://blogs.sun.com/bblfish/entry/i_have_a_foaf_file

> At the time, the topic seemed to be about URI fragments being used,  
> typically:- as references within an HTML serialization of a single  
> web resource, allowing hyperlinking within the stream. Chain(s) of  
> links connecting to one or more anchors, that is. I made some glib  
> comment, as a result.

I think it is really worth avoiding also getting into microformats  
and RDFa. Much easier to start by having a seperate foaf
file and link to it from the openid html web page. Learn N3 and  
download cwm. That will help make all this much easier to understand.

>
> In a context of discussing microformats within an HTML stream, I  
> had assumed folks were simply using URI fragments simply to locate  
> the FOAF data within an HTML stream. That is, the RDF metadata  
> representing authorization policy constraints imposed upon the web  
> resource serialized as the bearer HTML document was based on an  
> architecture involving (a) the FOAF extension of RDF, (b) an  
> incidental OWL-definition of the FOAF class of RDFs, (c)  
> microformat serialization of some actual RDF meta-data, (d) SPAQL  
> queries of that RDF metadata, serialized in an XHTML element, and  
> (d)  an incidental WSDL2 -description of the means of communicating  
> the SPAQL query req/resp against that element by a (remote) query  
> agent.
>
> But, I'm no longer sure I understand the fragment-id issue - (1) as  
> I know I don't fully understand the elements listed in the previous  
> paragraph, or their interaction (2) URI-based vocabularies are a  
> part of the RDF communities knowledge representation and handling  
> world, independent of locating XHTML elements bearing  
> microformatted datasets, and (3) FOAF references already assume  
> particular forms of URI in the spec's domain-based modeling of  
> "authorized relations amongst people".
>
> So, what my worry is...(being pretty dumb in data and knowledge  
> modeling)... that I'm missing a critical formal architectural  
> component, that I'm supposed to understand (being a security  
> specialist). If I concoct a term, there may be a missing formal  
> model of the 'identity semantics' - assumed by the FOAF world and  
> required when SPAQL engine queries the RDF... expressed in a  
> microformat element of the HTML document which the FOAF- 
> authorization policy constrains.
>
> So, at this point, my architecturally-challenged brain now  
> wonders... is there a more  fundamental issue about fragmentids in  
> OpenID at stake?
>
> For example: the normalized OpenID shall have certain form --  
> aligned with OpenID-specific  'identity semantics' -- specifically  
> in order that the OpenID URI is used consistently when one makes  
> statements in the "URI vocabulary" defined by the "OpenID-profiled,  
> FOAF extension of" RDF?
>
>
>
>
>
>
>
>
>
>
>
>
>




More information about the general mailing list