W3C home > Mailing lists > Public > semantic-web@w3.org > February 2006

Re: SemWeb CMS question

From: Daniel Harris <daniel@kendra.org.uk>
Date: Mon, 20 Feb 2006 10:07:01 +0000
Message-Id: <DCF6E06A-4D29-4E3C-A397-9D1C3BD57D66@kendra.org.uk>
Cc: Semantic Web <semantic-web@w3.org>
To: ben syverson <w3@likn.org>

Hi Ben,

This is an interesting quandary. We are coming across similar issues  
with our Kendra Base prototype. A few points that spring to mind:

- I'm not sure but it seems that you have one name space in your  
system. The way we are modeling Kendra Base is to have one name space  
per user. All assertions made by a user are marked as such. In the  
real world people say the same words but mean different things so we  
need to allow for that.

- Where is the issue of trust in terms of assertions made. Do I trust  
all assertions in your system? Can I select the users which I trust  
and the assertions which I trust? Both of which will impact on the  
results of any query/search I make.

- I'm unsure how you have implemented "Everyone in the community  
agrees, and the model shifts". Surely, everybody is just making  
assertions. And they agree by making an assertion that looks like:  
when I say blah1574 it means the same as when John476 says blah68547.

- You talk about an and "outdated relationship" and "ambiguous"  
relationships. To the author of those relationships they are most  
likely current and unambiguous. It depends from whose standpoint you  
are viewing the sea of assertions. So, I guess I'm unsure where your  
standpoint is; where you're viewing from.

Cheers Daniel

On 17 Feb 2006, at 21:33, ben syverson wrote:
>
> Hello,
>
> I took a break from likn, my semantic web CMS, but I'm returning to  
> it now, and finding that I still have one very fundamental issue to  
> work out: if likn allows users to dynamically build a vocabulary  
> and ontology, how do you handle changes?
>
> First, some background: likn is a CMS that allows its users to add  
> metadata and constraints to new or existing nodes via a chatbot  
> named qbot. All of these assertions are reified (internally only)  
> and evaluated based on popularity. This means likn and qbot display/ 
> return things like:
> "I'm pretty sure that the color of ben's hair is Brown"
>
> An important note is that there are no B-nodes, so every connecting  
> node is extant. That is, the above example would imply a node named  
> "ben's hair."
>
> These connecting nodes are created transparently during the  
> assertion dialog:
> User: "ben's hair is brown."
> qbot (to herself):
> * ben has component hair via human.
> * hair has property color
> * color has instance brown
> (to User): "Do you mean that the color of ben's hair is brown?"
> If the user confirms, the connecting node "ben's hair" is  
> established, and given the property color with the value brown.
>
> All of that works just dandy, but then someone comes along and  
> decides to refine the model: humans don't have hair, they have  
> bodies, and their bodies have hair. Furthermore, their bodies have  
> heads, and these heads have their own hair. Everyone in the  
> community agrees, and the model shifts.
>
> The problem is that ben is now saddled with an outdated  
> relationship. "Ben's hair" was precise when it was created, but now  
> it's ambiguous: does it mean "the hair of ben's body" or "the hair  
> of the head of ben's body?" It's easy enough to ask the user, but  
> as the system scales up, it means that thousands of relationships  
> could be instantly rendered ambiguous.
>
> One possible solution would be to add the additional assertion:  
> "human's hair is the same as the hair of the head of human's body"  
> in order to bridge the gap. The only drawback *there* is that the  
> node named "ben's hair" still remains, with its less-than-ideal  
> (and invariable) name.
>
> I don't know -- maybe I'm just talking myself through my issues in  
> public. Does anyone have any suggestions?
>
> - ben syverson
>
>
Received on Monday, 20 February 2006 10:07:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:49 UTC