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

Re: What is a WebID?

From: Nathan <nathan@webr3.org>
Date: Thu, 01 Nov 2012 01:44:17 +0000
Message-ID: <5091D3F1.7020301@webr3.org>
To: Kingsley Idehen <kidehen@openlinksw.com>
CC: public-xg-webid@w3.org
Kingsley Idehen wrote:
> On 10/31/12 8:37 PM, Nathan wrote:
>> Fair to say that in a nutshell, you'd be happy that every person who 
>> makes tooling to use with WebID should support every possible 
>> mediatype that can potentially hold the statements needed to verify a 
>> webid?
> This isn't the point Jurgen is making. Breaking URI opacity is simply 
> unacceptable and unnecessary.

Apologies, I thought he was making two points, one in relation to URI 
opacity (over which I have a pedantic preference, but don't feel too 
strongly about), the other in relation to having no constraints on 
mediatypes, something I do feel very strongly about - due to 
implementation complexity.

>> J├╝rgen Jakobitsch wrote:
>>> hi,
>>> i need to add my two cents to this thread and hereby invite the whole
>>> community to a big party the day the discussions about uris and
>>> serializations are over.
>>> both are abstract concepts and should thus be treated as such.
>>> we must accept the fact that uris come in different shapes, either is a
>>> URI (mr. jackson : i'm not going to spend my life being a color).
>>> going for one shape is a sign of non-algorithmic thinking.
>>> with serialization one can even take it one step further into the realm
>>> of fractal thinking.
>>> the physical world as we perceive it on a daily basis can be seen as a
>>> serialization of reality (followed by what some call nirvana in the next
>>> iteration) influenced by our accept headers (illusions). likewise 
>>> turtle, rdf+xml and co. are only forms of an idea that are of
>>> no interest. a tautology resolves to true, no matter in what language it
>>> is expressed.
>>> in my attempt to get rid of all illusions i not only oppose debates on
>>> what kind of uri to use but oppose all discussions on shapes.
>>> cnr turnguard
>>> On Wed, 2012-10-31 at 09:38 -0400, Kingsley Idehen wrote:
>>>> All,
>>>> In the last 48 hours following TPAC, a definition of what a WebID 
>>>> has emerged. It reads as follows: "WebID" (hash HTTP URI which 
>>>> denotes an Agent. Where you can GET an RDF model as TURTLE.) .
>>>> I believe this definition is unnecessary inflexible albeit well 
>>>> intended.
>>>> Problem:
>>>> A URI is an opaque identifier.
>>>> A Linked Data URI is a de-referencable URI that denotes an entity in 
>>>> such a way that when de-referenced said URI resolves to a 
>>>> description document of its referent. Put differently, you have two 
>>>> routes to the same document content i.e., the first being the entity 
>>>> name (URI) and the other being the entity description document 
>>>> address (URI/URL). Ideally, the content of the document in question 
>>>> takes the form of RDF model based structured data represented (or 
>>>> expressed) using an entity relationship graph.
>>>> A WebID supposed to be a Linked Data URI.
>>>> HTTP, hash URIs, and even the RDF data model are specific 
>>>> implementation details. They are collectively cost-effective and 
>>>> useful, but none of that makes them mandatory items for specs 
>>>> relating to Linked Data, Web-scale identity verification, or 
>>>> Web-scale resource access control.
>>>> The architecture of the Web is deliberately abstract thereby 
>>>> enabling powerful loose coupling of data access protocols, data 
>>>> representation formats, and semantics.
>>>> Simple Example:
>>>> At this point in time, should this definition hold, the hashless 
>>>> ProxyURIs that we use to watermark X.509 certificates for holders of 
>>>> LinkedIn, Twitter, Facebook, G+ etc.. accounts are all rendered non 
>>>> conforming, just like that.
>>>> Conclusion:
>>>> I am officially lodging my opposition to this definition of a URI 
>>>> that serves as a WebID.
Received on Thursday, 1 November 2012 01:45:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:56 UTC