RE: A question on the vocabulary for 'persons' - ACL level of granularity?

-- Matthias,

> > I actually think that each ontology designer should think 
> beyond its 
> > own community  because in the long run, we don't know how 
> things will 
> > be interact with each other.
> 
> But thats the problem. It would be quite hard for ontology 
> developers to anticipate all possible contexts of the use of 
> an ontology and to modularize it accordingly. The 
> computer-geeks developing foaf some years ago did not 
> anticipate that some life science-geeks would not like to 
> have properties for geekcodes in their ontology. The 
> developers of some top-level ontology that makes 'protein' a 
> subclass of 'food' did not either. Even small disagreements 
> can become quite annoying, and it would increase the effort 
> needed for ontology development quite a bit. 
> Furthermore, highly modularized ontologies that use many 
> cascading owl:imports are also quite hard to work with in 
> practice. For example, I couldn't work on an ontology that 
> had some cascading imports that led to the 
> protege.stanford.edu website when the website was down. 
> Protgege just gave up because one of the imports in the 
> cascade could not be loaded. Very, very annoying.
> Leaving it to 'ontology re-users' to excise the parts of the 
> original ontology they want to use in their own work takes 
> some burden off the shoulders of ontology developers. It also 
> gives ontology re-users more freedom to choose.

Sure, it is hard and as I said before, there is no clear cut objective
guideline to draw the boundary of domain knowledge.  However, if we all
think carefully, it will minimize the problem.  Take FOAF for example, is
the foaf:Person a concept intended to be specific to the online community?
If the answer is yes, then the foaf:Person would not be the same concept of
Person as we will generally agree.  But specify it clearly and we won't have
this discussion right?  But if the answer is no.  Then, I think it should be
separate it out to another ontology/namespace.  The same goes with the
"food:Protein" example, in that case, I doubt the food:Protein means the
same as biology:Protein. Of course, they are very much related, but they did
not refer to the same concept.

The annoyance of this "cascade import" is not essential.  Eventually, there
will be tool support for caching and helping you out.  Besides, as both Dan
and Drew have mentioned, ontology usage is going to be "pick-and-mix", the
"import" thing is actually a neat feature of the web.  No matter how you
want to get a part of one ontology, you cannot avoid multiple imports.  And
as a matter of fact, we should encourage the multiple import because it
prevent people from reinventing the wheel and it promote sharing and
therefore better communication.

> > The foaf:geekcode example is a figure of speech especially 
> with Chris'
> > objection to foaf. I certainly wouldn't expect that Chris 
> or anyonelse 
> > in that matter would in fact make some statement to 
> recommend not to 
> > use certain (or even part of an) ontology
> 
> I am not sure if I understood you correctly. However, I think 
> it  is a very realistic use-case that someone does want to 
> re-use some parts of an ontology while leaving out others, 
> simply because some parts are not NEEDED for the application 
> (not because it would contradict some other statements in the 
> ontology). An example would be the creation of GUIs. An 
> appliaction that uses an ontology that is perfectly fit for 
> the use of the application could generate a form for editing 
> information about a person simply by querying all of the 
> possible properties for an instance of the person class. On 
> the other hand, an application that uses an ontology with a 
> lot of unwanted properties would need to take additional 
> actions to show only the needed properties and suppress the 
> unwanted properties.

Of course, most ontology's use is partial.  For instance, not many users
will use all aspects of the dubline core. There are two issues here.  The
first one is to generate an ontology, which in turn uses other ontology.
The second one is to use an ontology for some application logic.  I think
the GUI example is in the second category.  And the unwanted part of an
ontology do not post too much problem.  But in the first case, i.e.,
building ontology with other ontology, there is potential risk if the
imported ontology is not carefully modulized.

What gets me into this problem is at one time I wanted to use part of the
MGED ontology. I was thinking to put up something for proteomics.  But I
wish it could be potentially connected to genomics as well.  MGED has some
concept, for instance, mged:Experiment, that I think I could reuse. But in
order to do so, I have to import all the classes and properties of the MGED
ontology, which has close to 1000 concepts.  Using Jena on my laptop even
turning on some limited reasoning ability will get me an out-of-memory
error.  Let's put aside other issues, (for instance the strange inheritance
where in MGED everything is a mged:Ontology), just this monolithic nature of
the ontology will prevent me from reusing it.  Then, I will have to create
my own Experiment class.  Someonelse will very likely to do the same, then
after a few years, there are tens/hundreds of Experiments out there, each of
which might have slightly different semantics for their constraints. We will
have to start trying to align them, just as a lot of people trying to do
with the database schema.  But, if we all have a bit of forward thinking
about how the ontological world is going to be in the semantic web, we
should be able to prevent the mess from happening.  Or at least create a
mess on a much smaller scale if each ontology is carefully modulized.  These
extra effort, i.e., breaking a big ontology into multiple small ones and
subsequently pieces them together, will pay off in a long run.  Well, at
least this is what I think. Of course, I could be wrong but what are other
choices?

Xiaoshu

Received on Monday, 18 September 2006 15:08:48 UTC