- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 02 Dec 2011 17:52:47 -0500
- To: public-xg-webid@w3.org
- Message-ID: <4ED956BF.9040207@openlinksw.com>
On 12/2/11 5:24 PM, Henry Story wrote: > > On 2 Dec 2011, at 23:03, Kingsley Idehen wrote: > >> On 12/2/11 4:41 PM, Henry Story wrote: >>> >>> your isse was you said you had a the following urls >>> >>> * http://yorkporc.blogspot.com/ >>> * http://yorkporc.blogspot.com/# >>> * http://yorkporc.blogspot.com/2011/11/2uri.html#me >>> >>> >>> So whichever ones satisfy the query is the one the server can use to >>> identify you, including all three if they all verify. >> Yes, but when we have a world of verified WebIDs the next step is to >> do something. That's when ambiguity runs wild, as you know. > > The semantic web manages to push back many kinds of ambiguity, more so > than most other systems. Formally there is no ambiguity in RDF. But > really all languages are evolving systems, and since we all have > different background beliefs, and desires, people will come to > different conclusions even when given the same information. But this > topic is a really hard topic, and not one to broach casually. > > David Lewis has a very good set of papers one of which is called > Language and Languages where he studied what a language is > mathematically, and how even mathematical objects such as that can > evolve. Essentially there are an infinite number of languages that fit > our linguistic behaviour. We choose from time to time to select some > terms in a certain way, and thereby we all narrow down among the > possible languages we were speaking. > > It is important to understand that this does not mean that everything > goes. In his analysis of convention David Lewis starts with the > convention of driving on the right hand side in France and the US as > an example. Now there are some very good reasons to continue driving > on the right hand side, if everyone around you is driving that way. > Words and URLs get their meaning in similar ways. > > So those were just some pointers to serious philosophical works in the > space of meaning. > > But you are right, if one has a few WebIDs one then has do something > with them. I would start simple there, and see how things go as we > move along. As we see issues in our interaction we will then establish > rules to help us along. But there is no point restricting the space > before hand. > > Perhaps that is the greatest thing about David Lewis : his way of > never closing doors, and leaving as many possibilities open. Yes, so we can tell people to use # URIs if the IdP space hosted claims graph takes the from of an (X)HTML document. Basically, when cut and paste is the pattern stick with # URIs since Name/Address disambiguation costs are low. For verifiers they have to understand that you can verify a WebID how ever you wish, but do note that ambiguity could ultimately compromise post authentication utility of said WebIDs. Alternatively, and this tends to work the most for we humans: wait until ambiguity bites, then adjust accordingly :-) Kingsley > >> >> As per usual, in my last post I forgot to attach a link re. my [1] >> reference to JSON-LD. >> >> Links: >> >> 1. http://json-ld.org/requirements/latest/ -- it covers Linked Data >> well i.e., negates httpRange-14 imbroglio trap. >> >> -- >> >> Regards, >> >> 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 >> >> >> >> > > Social Web Architect > http://bblfish.net/ > -- Regards, 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Friday, 2 December 2011 22:53:15 UTC