Re: "In Defense of Ambiguity"

Hi Alan:
Basically all I wanted to say is that in human communication, we clarify 
and refine the meaning associated to words in the course of 
communication, while the current SW infrastructure requires us to define 
the meaning of a conceptual element identified by a URI beforehand. 
Quite clearly, there can be multiple similar elements with different 
URIs. But we cannot currently negotiate the meaning of this very URI.

My main concern is that reducing query answering to querying a static 
representation may be too simple an approach, same as matchmaking for 
needed products is not a simple query, but often a complex communication 
process. For example, we learn of the option space by seeing the results 
to our initial queries and then typically refine our usage of the 
vocabulary.

"..Language is a living organism that adapts to the development and the 
trends of society as a whole."[1]

Best


Martin


[1] Umberto Eco in his nice preface "The Meaning of The Meaning of 
Meaning" to Ogden/Richards „The Meaning of Meaning“

Alan Ruttenberg wrote:
>
> On Jul 11, 2008, at 6:09 PM, Booth, David (HP Software - Boston) wrote:
>
>>> On Jul 10, 2008, at 7:09 PM, Martin Hepp wrote:
>>>
>>> Current ontology infrastructure requires that we reach
>>> consensus first. Human communication on the contrary allows
>>> us to postpone dispute and clarification to a later point in
>>> time in which the disagreement becomes relevant, if it ever
>>> gets relevant.
>>
>> This sounds overly pessimistic to me. Yes, some things in the 
>> semantic web *do* need to be agreed in advance, such as the general 
>> rules for determining the meaning of a statement. But individual 
>> ontologies do not -- they can be developed independently and only 
>> adopted as needed -- and there is nothing to stop an application from 
>> taking a lazy evaluation approach to semantic web data just as humans 
>> do. An application could postpone determining the meaning of a 
>> particular RDF statement (which involves determining the meaning of 
>> its constituent URIs) until it is needed
>
> Huh? Figuring out exactly what someone meant when they said something 
> after the fact is a huge problem. In a previous job it was routine to 
> go around to the various people who documented their experiments in 
> lab books because the lab books in isolation were too difficult to 
> understand. Understanding them after the people who wrote them left 
> the company was often impossible.
>
> If people can't do it, why would you expect some application would?
>
>> , sort of like a backward chaining reasoning style: start with the 
>> goal, and then figure out what information is needed to reach that goal.
>
> The problem is that the information is encoded in the language used in 
> the statement. If you don't understand the terms you can't even get at 
> the information.
>
>> And if a particular statement never ends up being needed, so be it.
>
> Sure. But if a statement *is* needed you're out of luck.
>
> -Alan
>
>

-- 

-----------------------------------
martin hepp, http://www.heppnetz.de
mhepp@computer.org, skype mfhepp