Re: [OEP] public comment

Peter, Natasha

I think that the translation may be simpler than indicated.  I've talked to people actually using OWL ontologies here and also have two MSc students working on a SW project using OWL ontologies.

It ties into the issue of Pre-coordination vs Post-coordination that I think we may have to tackle explicitly somehow.

In the simple cases what they have done is to build the domain ontology in OWL-DL, classify it to get the structure right and provably consistent, and then save it with all the classifications to form a "Pre-coordinated" ontology.  Since the ontology is now pre-coordinated, there is no need to use DL reasoning on it further.

Then they have created a new ontology and imported the now fully classified ontology.

They hey make statements such as dc:subject hasValue( Class).   They then query it using RDQL or one of its variants.  The same thing could have been done annotating in RDF(S) directly.

If you specify the OWL-Lite model in JENA/RDQL you get the query result you want, although the query has to specify explicitly the recursion on rdfs:subclassOf.

So it looks to me like the layering at least sort-of works.  I know this is a very tool specific answer. But it is at least an existence proof that what is being suggested is potentially feasible with existing tools
It has the advantage that the RDQL query is closed world which is normally what they want.

I would think that it would be possible to come up with a means of registering known properties such as dc:subject where the range included Classes in RDF that were to be transformed to someValuesfrom restrictions if needed in OWL-DL.

What it also requires is a way of indicating that an ontology is Precordinated and needs no more classification.  However, I think there are lots of reasons that this annotation for ontologies as a whole is required.

There are other "classes as values" issues that do not fit this use, case (e.g. "Endangered speciees").  However, for dealing with simple annotation, it seems to make sense.

I think that would leave us with just two patterns and a conversion between them. One using the property directly in an RDF(S) or as hasValue() in OWL-Full  with the understanding that no reasoning was to be done except to trace the subclass-superclass graph; the other using the property with someValuesfrom in OWL DL.  We need to sort out details of the annotations, but that doesn't sound insuperable.


Regards

Alan



Natasha Noy wrote:

> Peter,
>
> >> You have a point there, and others have raised similar issues [1],
> > [2].
> >> I am not sure (1) is a feasible option though -- see my reply to Brian
> >> today. On (2) indeed translations between patterns would be helpful.
> >> Short of providing the translation tools themselves what type of
> >> information should we provide in the note to enable  tool developers
> > to
> >> write conversions?
> >
> > Let me just brainstorm aloud and correct me later if my logic goes
> > astray somewhere.
>
> Thanks for the ideas! A few comments below.
>
> > Aldo and I have used the foundational approach in the past, but it
> > carries a lot of commitment, so now let's just look if it's possible to
> > find internal mappings. For the sake of argument, I'll try to map
> > Approach 2-5 to Approach 1. (Simply by looking at the number of boxes,
> > Approach 1 seems to be the least expressive, which holds the promise
> > that we can project the other ontologies onto this one.)
>
> "Expressive" may not be the right word. I would actually say that
> Approach 1 is the most expressive since it uses constructs that are not
> available in other (DL) approaches. You are right though that it has
> fewer constructs and thus mapping to it is easier.
>
> however, it also seems that from the purely  pragmatic point of view,
> what people will need is the opposite translation. That is, if you want
> to allow editing in more natural (to many , at least) way, you want to
> edit using Approach 1 and then map it to OWL DL, using one of the other
> approaches. Thus, it seems that you will need the translation from
> Approach 1 to the 4 others at least as much as the reverse direction.
> And these translations are tricker, since they need to introduce new
> concepts (those extra boxes in the diagrams).
>
> So, if we want to do such an appendix, it seems that it should include
> translations in both directions).  I am not sure what the general
> feeling in the group is, in particular since we do not have any agreed
> upon formalism for rules yet, and here we will need to use existential
> qualifiers, skolems, or some such. Perhaps we'll bring it up in the
> telecon tomorrow.
>
> Natasha

--
Alan L Rector
Professor of Medical Informatics
Department of Computer Science
University of Manchester
Manchester M13 9PL, UK
TEL: +44-161-275-6188/6149/7183
FAX: +44-161-275-6236/6204
Room: 2.88a, Kilburn Building
email: rector@cs.man.ac.uk
web: www.cs.man.ac.uk/mig
        www.opengalen.org
        www.clinical-escience.org

Received on Thursday, 10 June 2004 08:29:03 UTC