Re: UC&R 4.6 use case and discussion

On Thu, Sep 16, 2004 at 08:08:22AM -0500, Kendall Clark wrote:
> 
> Okay, I asked for a use case from Aditya in our lab, and he sent me this; I
> could write a "proper" use case from this, and I think it's interesting
> standalone.
> 
> Kendall
> --
> Most API to parse ontologies such as Jena and the Manchester OWL API have a
> basic reasoning service (or query language from another angle) that isn't as
> sound and complete as a RACER or Pellet say, but provides some fast and
> convenient services for obtaining useful semantic information about an
> ontology. These would be very useful in an RDF Query Language as well. For
> example (some of them are RQL like),

Refactoring a bit, I think that the only piece we don't have is
"direct".  The rest of the semantics are projected onto graph patterns
in the OWL spec. Assuming the subject <foo> for all these queries:

> class.getEquivalentClasses(ontologies, direct)

<foo> owl:equivalentClass ?x

> class.getSubClasses(ontologies, direct)

?x rdfs:subClassOf <foo>

> class.getSuperClasses(ontologies, direct)

<foo> rdfs:subClassOf ?x

> class.getDisjointClasses(ontologies, direct)

<foo> owl:disjointWith ?x

> class.getProperties(ontologies, direct) // get all object/datatype
> properties who's domain is the class

?x rdfs:Domain <foo>

> class.getIndividuals(ontologies, direct)

This one seems tougher. I am also not sure I understand it
(related?). Is it supposed to return all the known distinct
individuals? The query constructor would have to deduce all the graph
patterns that could cause an inferencing engine to deduce that two
nodes are distinct, which is no harder than writing a description
logic engine in, say, BRQL.

My guess is that the biggest payback will be for "direct". SeRQL folks
included direct subclass so maybe someone asked for it?

It would be cool to implement "direct" through an extension mechanism,
both because it is outside the task of simple graph match (and is
outside the RDF model), and because it would give our extension
mechanism some needed excercise.

> where the "ontologies" parameter is used to specify the context for the
> query since the same class (URI) can have different axiomatic definitions in
> different ontologies, and "direct" is used to specify whether a transitive
> closure of the query should be taken or not (similar to the ^ operator in
> RQL). The first three methods above are useful for creating a class tree
> hierarchy, even if they support only named classes (i.e. no anonymous
> entities in the return set). This is almost a necessary feature in any
> ontology editor/visualizer. Also, the methods seem straightforward enough to
> implement and don't require any complicated inferencing algorithm. Finally,
> construction of the tree hierarchy enables more useful queries such as
> NearestCommonNamedAncestor(class1, class2,..) (since farthest would
> obviously be owl:Thing) etc.
> 
> The last two methods above are very useful from the instance support point
> of view in an ontology editor (w/ the getProperties method providing slots
> for a more frame-based view). It would be nice to treat Properties
> separately as Object and Datatype Properties in some queries esp. since OWL
> (Lite & DL) enforces that distinction.
> 
> The corresponding methods exist for properties to extract a property tree
> hierarchy. Other (related) useful queries for extracting semantic
> information about properties would be:
> 
> property.getDomainsOf(ontologies, direct) //return all classes in
> domain of property
> property.getRangesOf(ontologies, direct)
> 
> and for individuals..
> 
> individual.getTypes(ontologies, direct)
> individual.getProperties(ontologies, direct) // combination of
> individual.getTypes(..) to get class set and class.getProperties(..)
> for each class type
> individual.getSame(ontologies, direct)
> individual.getDifferent(ontologies, direct)
> 
> There are obviously more complicated queries I haven't considered, which
> would involve advanced inferencing and hence considerably slow down the
> querying process. All I know is that having these basic queries would make
> use of the semantic information in the ontology to better enable ontology
> visualization/editing. I'll let you know if I can think of others I might
> have missed out.
> 
> Cheers,
> Aditya

-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741 (does not work in Asia)

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.