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

Descriptors, Discovery, and Hammer Stack

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 11 Jan 2012 09:57:03 -0500
Message-ID: <4F0DA33F.8020806@openlinksw.com>
To: WebID XG <public-xg-webid@w3.org>

Another important FYI: http://hueniverse.com/discovery/ .

Hoping at the very least, this sheds light on why I use terms like: 
descriptor (information) resource, instead of esoteric terms such as:

1. information resource
2. document (without context qualification).

This ultimately goes back to my point about de-referencable URIs and 
their impact on x.509 certificates that bear URIs servings as WebID 

A URI can serve as Name or an Address. It can also serve as a 
Name/Address combo; basically, this is what you get with an HTTP URI 
based Name.

What does this means for WebID in general?

1. who bears the responsibility of groking the naunces associated with 
Linked Data?
2. how do we achieve WebID verification via lookups via certificates 
that accommodate both URI roles (or senses) via distinct slots i.e., SAN 
for Names and some other slot for Addresses?

At this juncture, I don't need responses arguing validity etc.. The onus 
is on me (as already stated in other threads) to demonstrate a solution 
that showcases the problem and the solution. Just as I did yesterday re. 
slash based URIs in SAN.  I'll be getting that done as promised!



Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Wednesday, 11 January 2012 14:57:29 UTC

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