Re: What is a WebID?

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