W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2004

RE: use case: finding employees by type (disjunction and OWL)

From: Jos De_Roo <jos.deroo@agfa.com>
Date: Mon, 12 Apr 2004 19:17:53 +0200
To: Rob.Shearer@networkinference.com
Cc: "Dan Connolly" <connolly@w3.org>, "RDF Data Access Working Group" <public-rdf-dawg@w3.org>
Message-ID: <OF11CB59CE.D4BEDC46-ONC1256E74.005D98E7-C1256E74.005F01DF@agfa.com>

Rob, I'm also afraid that I don't follow...
Could you maybe formulate your original use case
as a test case

given following triples:
...

asking following triples:
...


(my test case was 
given following triples:
:Bob rdf:type :Management.

asking following triples:
:Bob rdf:type _:a1.
_:a1 owl:unionOf _:b1.
_:b1 rdf:first :Management.
_:b1 rdf:rest _:b2.
_:b2 rdf:first :Support.
_:b2 rdf:rest> rdf:nil.

and there is no named concept used for
"Management or Support" btw)


-- 
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/




"Rob Shearer" <Rob.Shearer@networkinference.com>
12/04/2004 18:49

 
        To:     Jos De_Roo/AMDUS/MOR/Agfa-NV/BE/BAYER@AGFA
        cc:     "Dan Connolly" <connolly@w3.org>, "RDF Data Access Working Group" 
<public-rdf-dawg@w3.org>
        Subject:        RE: use case: finding employees by type (disjunction and OWL)


I think we've jumped from the original use case to one that we know is
easy.

Inferring that Bob is in "Management or Support" from the fact that he
is in Management is straightforward and can be encoded as triples (if
"Management or Support" is a named concept in its own right, which is
the big problem with such an approach).

Inferring that Bob is in Management, or that he is in Support, from the
fact that he is in either one is just plain wrong.

There are several ways to approach this problem. Let's not enumerate
them.

I see the originally stated use case as a well-defined example of the
kinds of things for which people want to use OWL to supplement a flat
RDF store. I don't see any other use cases which demonstrate this user
need.

Does anyone agree that users want to do these kinds of things?

> -----Original Message-----
> From: Jos De_Roo [mailto:jos.deroo@agfa.com] 
> Sent: 12 April 2004 09:39
> To: Rob Shearer
> Cc: Dan Connolly; RDF Data Access Working Group
> Subject: RE: use case: finding employees by type (disjunction and OWL)
> 
> 
> >>> Note that this use case is *not* subsumed by any other we are
> >>> considering. The use of disjunction makes the OWL ontology 
> >>> incompatible
> >>> with the naive "inferred triples" model.
> >> 
> >> I don't believe so. It's straightforward to infer
> >>               Bob rdf:type ManagementOrSupport
> >> from
> >>               Bob rdf:type Management
> >> and
> >>               ManagementOrSupport owl:unionOf (Management Support).
> >> 
> >> Using hasGroup rather than rdf:type is slightly more tedious,
> >> but just as doable.
> >
> > I'm afraid I don't entirely understand your technique. How 
> can such an
> > approach be used to solve the use case?
> >
> > I was thinking that the user should be able to query for 
> employees in
> > the Management or Support groups with a simple query on the RDF.
> > Ideally, the OWL ontology shouldn't require them to completely
> > reformulate their query. (An approach that uses owl 
> constructs even for
> > plain RDF queries is one solution.)
> 
> trying to test that, I queried
> :Bob a :Management.
> 
> with
> :Bob a [ owl:unionOf (:Management :Support)].
> 
> and got back
> _:27_3 owl:unionOf _:28_3. 
> _:28_3 rdf:first :Management. 
> _:28_3 rdf:rest _:29_3. 
> _:29_3 rdf:first :Support. 
> _:29_3 rdf:rest> rdf:nil. 
> :Bob a _:27_3. 
> 
> so that succeeded (*)
> 
> 
> -- 
> Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/
> 
> 
> (*)the latter triple was in detail inferred as
> 
>  {
>   <http://www.agfa.com/w3c/euler/owl-rules#owl9u1>. 
>   _:27_3 owl:unionOf _:28_3. 
>    {
>     <http://www.agfa.com/w3c/euler/owl-rules#owl42s1>. 
>     _:28_3 rdf:first :Management. 
>     :Bob a :Management} =>
>   {:Bob ns0:inSomeOf _:28_3}} =>
> {:Bob a _:27_3}.
> 
Received on Monday, 12 April 2004 13:18:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:19 GMT