Re: telconf 07-11-2012 : what is webid

On 15 Nov 2012, at 15:34, Andrei SAMBRA <andrei.sambra@gmail.com> wrote:

> Hello all,
> 
> Sorry for the late reply, I somehow missed this email when it was sent.
> 
> On Sat, Nov 10, 2012 at 3:10 AM, Henry Story <henry.story@bblfish.net> wrote:
> 
> On 10 Nov 2012, at 02:14, Jürgen Jakobitsch <j.jakobitsch@semantic-web.at> wrote:
> > hi,
> >
> > just two small notes on today's telconf and the definition of what a
> > webID is.
> 
> the minutes are here btw,
>    http://www.w3.org/2012/11/09-webid-minutes.html
> 
> (Btw, there are still a few edits I would like to do that doc.
> Anyone know how I should go about doing that?)
> 
> >
> > 1. just to keep us out of troubles, i took a look around and found that
> > the domain of predicate "denote" is widely used to be "URI" [1][2][3].
> > none of the rare cases i found was something like "URL denote".
> 
> I think that is ok. http://tools.ietf.org/html/rfc3986#section-1.1.3
> 
>    A URI can be further classified as a locator, a name, or both.  The
>    term "Uniform Resource Locator" (URL) refers to the subset of URIs
>    that, in addition to identifying a resource, provide a means of
>    locating the resource by describing its primary access mechanism
>    (e.g., its network "location").
> 
> So I am not sure if a WebID such as http://joe.example/#me is a URL or
> not yet. Even if it were a URL it would also be a URI and so denote.
> ( Still it says that future specs should use the term URI. )
> 
> This is an issue that has been discussed for a long time and I think the general consensus is that URL is a deprecated term for a URI that includes the network location and scheme. URLs do not necessarily need to include the protocol, they just give the location (i.e. example.com), which in fact can be http://, ftp://, etc.

That is wrong. You need to look at the URL spec. especially the ebnf:

 http://tools.ietf.org/html/rfc1738#section-5

genericurl     = scheme ":" schemepart

so "example.com" is not a URL.

> On the other hand, URIs always designate a method to access the resource and designate the specific resource to be accessed (i.e. http://example.com/card#me). I think we should proceed to using URIs instead of URLs, especially since we're going to push WebID adoption over the HTTP scheme (afaik from TPAC).

I think it is clear that the only thing WebID Auth makes sense is for the WebID to be a URL. Ie it really does not make much sense with URNs which have no clear way of being dereferenced.

On the other hand URLs are still too general. mailto urls are still part of the URL spec. I think there is no need for us to be so general as to have all URL types because we can tie all the other authentication schemes together using Identity Interoperability

   http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability

Restricting ourselves to http, https URLs does make for a clearer spec, without 
creating interoperability issues. I can see that ftp and ftps would also work, but
we would certainly have a more testable system if we limited ourselves at first.

I think .onion and .galic urls can be deal with as proxy routing schemes.

>  
> What we need to describe is first something more general that the LDP
> spec needs to define perhaps, or that we need to define: and that is a URI
> that has a canonical method for dereferencing its sense ( or if you prefer
> its definition ), and that this definition in priority identify the meaning
> of the term. This is core to how linked data works because the owner of the
> URL namespace has priority in defining the meaning of the terms that are
> there.  We could call this a Linked Data Identifier (LDI).
> 
> It is important to see the difference. If in my profile at
> <http://bblfish.net/people/henry/card> I describe Tim Berners Lee
> 
> <http://www.w3.org/People/Berners-Lee/card#i> a animal:Lion;
>      ....
> 
> then I am not defining the meaning of that term. I can't: the namespace
> does not belong to me. The namespace is not related to the document that
> made that statement. The document that defines TimBLs URI is canonically
> related to the to the URI <http://www.w3.org/People/Berners-Lee/card#i>,
> that means one has to look at the protocol part of that document.
> 
> This is what an LDI should be.
> 
> You can call this URI whatever you like, I doubt it's not going to make it into the LDP spec. Because of the LD part in LDP, applications will always set the appropriate Accept: header in order to ask for RDF data, which defies the purpose of knowing beforehand what kind of identifier it is.

I think TimBL made clear at TPAC that this is not the case. A request on an LDP server without an Accept 
header MUST return Turtle. 

> The whole point of Linked Data is that URIs need to be dereferenceable

agree

> (is this even a word?). 

http://en.wiktionary.org/wiki/dereferenceable

> 
>  
> 
> Extra features
> --------------
> 
> Now a WebId is just a subset of such LDI's referring to agents.
> 
> But I think we may need to also add that the Agent Referred to by a WebID
> also is aware/ in control of the WebID. This is because we need to make
> sense of talk such as
> 
>  a. "my WebID is...",
>  b. "you can link to my WebID here...",
>  c. "what is your WebID?"
>  d. "Don't link to that URL, that's not my WebID - someone just made a copy of my
> profile there",
>  e. "I have three WebIDs".
>  f. "That is not my WebID, that's a wikipedia page about me :-)"
> 
> The point is we don't want a description of someone on Wikipedia to be considered
> a WebID just because it uniquely identifies that person. If the person cannot be
> considered to be  in charge or responsible for what is said there then it is just
> a URI describing that person. If it uses RDF then we can say that it is an LDI. But
> a WebID requires some notion of responsibility of the owner: for example I should
> need to know that if I loose my private key I need to update my WebID profile. (
> This may involve contacting the bank ) I don't need to update all the copies of
> my profile people made. I don't need to ask people I don't know about to update
> their databases about me. Even though other LDIs correctly and uniquely identify
> me a WebID is something I am in charge of.
> 
> I think the previous points (except the last one) were solved the moment we decided to split WebID into identity and authentication. The difference between MY WebID and a wiki page about me is that a URI becomes a WebID AFTER the user has successfully authenticated using this particular URI.

yes, if it is part of an WebID over TLS spec that kind of is assumed. But given that
we are now defining a WebID in more general terms it seems to me one should 
make this clearer. You think it is, but others will not.


> We learn two things here: first is that there was a deliberate association between the URI and a set of user credentials (certificate in the case of WebID-TLS), and second that the user himself/herself indicated that this particular URI is his/her WebID by deliberately authenticating with it. Basically, we don't care whether a URI is a WebID or not until it is used during an authentication sequence.

That is not at all what the proponents of the new definition have been arguing. Some want
to say things such as "what is your WebID? I would like to link to it" . That is perhaps the best reason
for people wanting to separate the definition of WebID from the authentication scheme. 

Still I get your point. If I ask you want your WebID is, then I am perhaps doing that after calling you
having found the number in your webid profile, and if you tell me that your WebID is the WebID 
on the Web then that counts as proof. 

Anyway, currently we have been saying that 

<blockquote cite="https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html">
A URI that refers to an Agent - Person, Robot, Group or other thing that can have Intentions. The WebID should be a URI which when dereferenced returns a representation whose description uniquely identifies the Agent who is the controller of a public key. In our example the WebID refers to Bob. A WebID is usually a URL with a #tag, as the meaning of such a URL is defined in the document refered to by the WebID URL without the #tag .
</blockquote>

Now this does not stop people linking to a WebID btw.

What they seem to have wanted is that one could link to it and not publish a public key there. So they 
want the following <#me> to also be a WebID if it links to a document that returns the following graph

{ <#me> foaf:openid <> . 
  <> openid:openid <http://someopenid.org/verifier>  }

or even the following graph

{   <#i> foaf:name "Jack Welsh"; 
            socialSecurityNumber "12312311231" . }
             
 But do they also want an empty graph? That was not clear from the talk at TPAC.

Btw, we also defined a WebID profile as:         

<blockquote cite="https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html">
A structured document asserting the relationship between the Subject (identified by his WebID) and his Public Keys using relationships as defined by the Resource Description Framework [RDF-CONCEPTS] and published at the URL location of the Subject's WebID. Dereferencing the WebID should return the Profile Page in one of a number of formats. The Server must publish the document in at least the RDFa [RDFA-CORE] serialization format or in Turtle [TURTLE-TR]. The document may be published in a number of other RDF serialization formats, such as RDF/XML [RDF-PRIMER], or N3 [N3]. Any other serializations that intend to be used by the WebID Protocol must be transformable automatically and in a standard manner to an RDF Graph, using technologies such as GRDDL [GRDDL-PRIMER].
</blockquote>


   So what people at TPAC wanted is for a URL to be just about a person. But that just seems too vague to me. 
You need to specify how it identifies the person, or why it is a URL about someone at all.  Otherwise one may as well just use the generic term URL or URI. Or do we also want new names for crystal URIs, or spoon URIs, ...? So I think the definition at TPAC was not quite complete.


Still limiting to a #url does make the following clear.

1. a WebID is an http or https URI that denotes an agent
2. a WebID must have a WebID profile associated with it, which can be fetched by dereferencing
   the WebID
3. the WebID Profile must contain a unique description of the agent referred to by the WebID
   such that one can prove using that description that an agent is the referent of that WebID






>  
> Andrei
> 
> >
> > 2. the "uniquely" thing.
> > using IFPs requires knowledge about the property itself. is there any
> > problem with that?
> > an agent might (will in most cases) need to get the property's
> > description also.
> 
> It either knows it or got it beforehand. For well known vocabularies
> people end up hard coding this knowledge in the user agents. One need
> not use IFPs only. Functional Properties can also work, and OWL Keys too.
> There may even be ways of getting close enough probabilistically.
> 
> >
> > wkr turnguard
> >
> > [1] http://dbooth.org/2010/ambiguity/paper.html
> > [2] http://www.w3.org/wiki/SocialMeaning
> > [3] http://bit.ly/YTdz3N (as i understand it)
> >
> >
> > --
> > | Jürgen Jakobitsch,
> > | Software Developer
> > | Semantic Web Company GmbH
> > | Mariahilfer Straße 70 / Neubaugasse 1, Top 8
> > | A - 1070 Wien, Austria
> > | Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22
> >
> > COMPANY INFORMATION
> > | web       : http://www.semantic-web.at/
> > | foaf      : http://company.semantic-web.at/person/juergen_jakobitsch
> > PERSONAL INFORMATION
> > | web       : http://www.turnguard.com
> > | foaf      : http://www.turnguard.com/turnguard
> > | g+        : https://plus.google.com/111233759991616358206/posts
> > | skype     : jakobitsch-punkt
> > | xmlns:tg  = "http://www.turnguard.com/turnguard#"
> 
> Social Web Architect
> http://bblfish.net/
> 
> 

Social Web Architect
http://bblfish.net/