W3C home > Mailing lists > Public > public-lod@w3.org > November 2010

Re: Semantic Ambiguity

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Fri, 12 Nov 2010 10:26:30 -0500
Message-ID: <4CDD5CA6.4050602@openlinksw.com>
To: William Waites <ww@styx.org>
CC: Patrick Durusau <patrick@durusau.net>, Dave Reynolds <dave.e.reynolds@gmail.com>, "public-lod@w3.org" <public-lod@w3.org>
On 11/12/10 9:03 AM, William Waites wrote:
> On Fri, Nov 12, 2010 at 08:40:14AM -0500, Patrick Durusau wrote:
>> Semantic ambiguity isn't going to go away. It is part and parcel of the
>> very act of communication.
>> [...]
>> Witness the lack of uniform semantics in the linked data community over
>> something as common as sameAs. As the linked data community expands, so
>> are the number of interpretations of sameAs.
>> Why can't we fashion solutions for how we are rather than wishing for
>> solution for how we aren't?
> I was at a lecture by Dave Robertson [0] the other day where
> he talked about some of the ideas behind one of his current
> projects [1]. Particularly relevant was the idea of completely
> abandoning any attempts at global semantics and instead working
> on making sure the semantics are clear on a local communication
> channel (as I understood it).

Yes, I am can express what I want in my Data Space. You don't have to 
make adopt my inference rules, likewise, you can't stop me from having 
them. It's my data space after all :-)

My Zebra might be your Stallion, that's just a claim in my data space, 
you don't have to believe it etc.. Luckily, I've lived in a number of 
countries, so appreciation of multiple world views is hard wired into my 
essence. I'll debate you, but still fundamentally understant that we 
should always be able to "agree to disagree".

> So maybe that would mean a different meaning for sameAs in
> different datasets, and that's just fine as long as the reader
> is aware of that and fasions some transformation from their
> notion of sameAs to their peer's, mutatis mutandis for other
> predicates and classes.

Yes, which is why we have the following capabilities in our platform 

1. Named Graphs
2. Backward- or Forward-Chained Inference capability
3. Conditional application of Inference Rules via SPARQL query process 

Its also why, when we add linksets to the Virtuoso instance hosting 
DBpedia, they end up in their specific Named Graphs, at least until 
there is general consensus re. addition to the main DBpedia Named Graph. 
Thus, people and user agents have access to DBpedia data via a variety 
of context lenses.

> In some ways this is similar to how we use language. If I'm
> talking to a computer scientist I'll use a different but
> overlapping sub-language of English than if I'm talking to the
> postman.


And once you speak more than one pure language or vernacular you 
experience this in full glory.

>   If I'm talking to a non-native English speaker I'll
> modify my speech so as to be more easily understood. Around
> here, "tea" means "supper" but a short distance to the South
> it more likely means a snack with cakes and cucumber sandwiches.

Some Africans don't see a Zebra or Horse as being different. Thus, they 
would refer to both as Horses. That doesn't make that a fact for the 
whole world.

> The important thing is a context of communication which modifies
> -- and disambiguates meaning.


> This might be touched on in the
> RDF Semantics with the not often mentioned idea of an
> interpretation of a graph.
> How does this square with the apparent tendency to want to treat
> statements as overarching universal truths?

There are no universal truth, bar the possibility that the 
aforementioned claim might be true :-)

> Cheers,
> -w
> [0] http://www.dai.ed.ac.uk/groups/ssp/members/dave.htm
> [1] http://socialcomputer.eu/



Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Received on Friday, 12 November 2010 15:27:04 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:51 UTC