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

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

From: Andrei SAMBRA <andrei.sambra@gmail.com>
Date: Thu, 15 Nov 2012 11:40:52 -0500
Message-ID: <CAFG79eh9_6-uNFFZFFJFKuv1g+OEg1u4g00myqrJS+L1zhMJpw@mail.gmail.com>
To: Henry Story <henry.story@bblfish.net>
Cc: public-webid <public-webid@w3.org>
On Thu, Nov 15, 2012 at 10:34 AM, Henry Story <henry.story@bblfish.net>wrote:

> 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.
> Yes, you are right. I went too fast through the rfc.

>  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.
We should remember that WebID is a _W3C_ group, not an IETF one.

> 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.

Yes, as long as you know it's an LDP server. LDP discovery/bootstrapping is
still an issue, in my opinion.

> 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.

I just think this is like saying a WebID is a UII (Uniform Identity
Identifier?), which doesn't really make sense to me.

> 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.
Indeed, but they ask _you_, the so-called owner of the WebID. When trying
to identify me (not authenticate) you would normally value my input more
than someone else's (i.e. a wikipedia link). It would be nice though to
have a pointer to your WebID inside the wikipedia page (something along the
lines of foaf:webid).

> 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<https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#dfn-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>

I think this definition could use some polishing. For example: "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." I see a few issues here.

First is "The WebID _should_ be a URI..."; why "should" and not "must"? Can
it be anything else?

Next, "... returns a representation whose description uniquely
identifies ..."; A "representation" is too vague. We are working with RDF,
which is an important keyword to have at this point, so why not having it
say "... returns an RDF representation ..."?

Next, "... identifies the Agent who is the controller of a public key ...";
isn't this only valid for WebID-TLS? I thought we were supposed to decouple
the authentication part, so why is there a mention of the public key?

> 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
> 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 Key<https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#dfn-public_key>s
> using relationships as defined by the Resource Description Framework [
> RDF-CONCEPTS<https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#bib-RDF-CONCEPTS>]
> and published at the URL location of the Subject's WebID. Dereferencing the
> WebID<https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#dfn-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<https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#bib-RDFA-CORE>]
> serialization format or in Turtle [TURTLE-TR<https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#bib-TURTLE-TR>].
> The document may be published in a number of other RDF serialization
> formats, such as RDF/XML [RDF-PRIMER<https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#bib-RDF-PRIMER>],
> or N3 [N3<https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#bib-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<https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#bib-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.

I agree about the definition not being complete. We can work on it in the
coming weeks.

> 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

 I completely agree. This is very clear to me.


> 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
>> >
>> > | web       : http://www.semantic-web.at/
>> > | foaf      : http://company.semantic-web.at/person/juergen_jakobitsch
>> > | 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/
Received on Thursday, 15 November 2012 16:41:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:38 UTC