RE: A long but hopefully interesting introduction

Hi Ben,

Sounds like a cool project. 

I've been thinking along somewhat similar lines recently. I've been thinking
about methods for evolving and propagating ontologies across a network of
users/agents. As a first step, I put together a sketch of a tag aggregator
that's driven by a collaboratively developed ontology (I called it
ontaggregator which confirmed my naming disorder to some :). See:

	http://labs.intellidimension.com/ontag/

I think the wiki model will work if you expect that the community of users
is like minded enough so that the ontology will converge. I think a
networked model, where nodes are connected to similar nodes and where
information propagates according to a support threshold, would allow
competing and divergent ontologies to develop and coexist. Sound like you're
talking about a bit of both?

More below...  

> -----Original Message-----
> From: semantic-web-request@w3.org [mailto:semantic-web-request@w3.org] On
> Behalf Of ben syverson
> Sent: Saturday, March 05, 2005 1:24 AM
> To: semantic-web@w3.org
> Cc: w3@likn.org
> Subject: A long but hopefully interesting introduction
> 
> 
[...]
> 
> 1) Each installation of the software will be building its own ontology
> as more information is added. The chatbot recognizes and happily
> digests statements such as "a person can only have one mother." Thus,
> the site's ontology is not fixed and carefully crafted, but public, not
> fully trustworthy, and ever evolving, which is, in my opinion, The Way
> It Should Be. The problem is that I'm concerned that this might violate
> the spirit of OWL; it's my understanding that OWL ontologies are meant
> to be stable, versioned and reusable, in the hopes that people will
> share or merge standard versions of them. 

It seems likely your ontology will converge to a semi-stable point which
will satisfy some. You could always publish stable snapshots for the rest.

 
> 2) Does anyone have any philosophical objections to using OWL Full to
> liberally allow Classes as Property Values? I read
> <http://www.w3.org/TR/swbp-classes-as-values/> with great interest, and
> would like to allow many relationships to form using the model
> described in Approach 1. I want to be able to preserve the ability to
> have the following exchange, without resorting to hackery such as
> intermediary nodes like "LionSubject":
> me: Lions: Life in the Pride's subject is Lions.
> likn: I assume you mean its subject is 'Lion?'
> me: Yup. Now tell me about lion.
> likn: Lion is a type of Animal, and is the subject of the book 'Lions:
> Life in the Pride.'
> ....
> In short, is there any good reason to explicitly separate Classes from
> Property Values, when it makes so much sense not to?

I doubt you could pull off what you describe and stay within the
restrictions of owl-dl, so you might as well go full (and use classes as
individuals).
 

> 4) One possibility is to allow the recognition/merging of other
> ontologies, but qualify their use within likn. For instance:
> me: tell me about dog
> likn: 'dog' is a type of animal, but according to AnimalNet, dog is a
> type of 'mammal.'
> Which is all well and good, but what if you want to create
> equivalences? If you want to say that our 'dog' is equal to AnimalNet's
> 'dog,' now anyone asking about dog gets something like:
> likn: 'dog' is a type of animal and a type of mammal.
> me: what's a mammal?
> likn: I don't know, but according to AnimalNet, mammal is a type of
> animal.
> Now we have two rivaling definitions of 'animal'. Likn could be smart
> enough to ignore redundant statements (given the two statements "ben is
> an instance of programmer" and "ben is an instance of person," likn
> will favor the more specific type of person), it can't (or shouldn't)
> automatically infer that AnimalNet's 'animal' is equivalent to our
> 'animal,' because our likn colony could in fact be a Muppet fansite,
> and 'Animal' could talk very specifically about the character of the
> same name (although in that case, no one would assert that 'dog' is
> type of animal). So things get very confusing and messy. Is there a
> good/established/proposed way of handling this? Possibly through
> reification?

One approach is to only disallow the import/merge if it creates an
inconsistency (and then choose to either disallow the whole merge or just
the offending statements). I've worked out an automatic inconsistency
resolution mechanism for this purpose. 


> 5) One aspect of the app is that users can vote on assertions. So if
> three people agree that "ben is an instance of person" and one person
> disagrees, likn is 75% sure that ben is a person. Is it best to do just
> do this via a reified statement such as the following?
> <rdf:Description>
>       <rdf:subject rdf:resource="http://likn.org/dog" />
>       <rdf:predicate rdf:resource="http://likn.org/footType" />
>       <rdf:object rdf:resource="http://likn.org/paw" />
>       <rdf:type
> rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement" />
>       <likn:confidence>75</likn:confidence>
> </rdf:Description>

I wondered about this too. It's tough because it probably drives you to some
form of probabilistic reasoning (which might be a good direction but
probably expands the scope of your project :-)

Of course you could always split the ontologies (in effect give each user
their own ontology). That's more the way I've looked at it - i.e. each user
has a view on the world, and is connected to those with similar views. New
information is propagated through the network according to some threshold
mechanism (e.g. two out of three of my friends believe fido is a dog, so I
guess fido is a dog; if I believe fido is a cat and cats are disjoint with
dogs than an inconsistency if created that will be automatically resolved
using least change heuristic).

> 6) Does anyone have any input, guidance or problems with my general
> approach, or specific aspects?
> 
> Anyway, thanks in advance -- and hello!
> 
> - ben syverson

Hope to hear more about your project.

Best,

Geoff

Received on Saturday, 5 March 2005 13:32:49 UTC