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

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


> 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. The
whole point of Linked Data is that URIs need to be dereferanceable (is this
even a word?).



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

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