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

ebXML Registry UC (Was Re: Agenda: RDF Data Access 27 Jul 2004)

From: Farrukh Najmi <Farrukh.Najmi@Sun.COM>
Date: Tue, 03 Aug 2004 10:26:17 -0400
To: Rob Shearer <Rob.Shearer@networkinference.com>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Message-id: <410FA089.2040709@sun.com>

Rob Shearer wrote:

>Greetings, Farrukh!
>Apologies for not initiating contact myself.
>Your use case came up at the face-to-face, and I was curious whether
>there were alternative ways to achieve the results you were trying to
>You suggest a method of "query refinement" to select the elements of an
>ontology in which you're interested: first do a general query, then add
>a few more qualifying predicates, then add a few more, each time taking
>a look at the result set and figuring out what to add to prune out the
>results in which you're not interested. (Please correct the most
>offensive bits of this crude summary.)
>In traditional description logics systems, the process of "concept
>refinement" is most commonly implemented by traversing a concept
>taxonomy using not just "subclass"-style edges, but rather
>"direct-subclass" relationships. For example, a taxonomy of "Worker",
>"White-Collar Worker", and "Accountant" would include both "White-Collar
>Worker" and "Accountant" as subclasses of "Worker", however only
>"White-Collar Worker" would be a direct subclass.
>The common use pattern would be a user interested in "Worker", so the
>user asks for the direct subs of worker and finds that they are "White
>Collar", "Blue Collar", "Service", and "Military". He can then drill
>down on whichever of these he wishes, each time getting a fairly small
>and easily-consumed result set. This is usually much easier to manage
>than trying to figure out how to refine hundreds, thousands, or millions
>of results by hand somehow.
>Is any approach along these lines applicable to your use case? 
I totally agree with sub-class refinement as the most common narrowing

The use case envision the query to have zero or more parameters. Any one
of the parameters
MAY be a Concept in a taxonomy (or a class in an Ontology).

This is implied but not stated in the use case as I was trying to have a
description that was easy to follow and conveyed the core use case.

If you would like to propose a modified version to the use case text
send me a draft and
we can try and reach closure on the issue before the next DAWG meeting if

Received on Tuesday, 3 August 2004 10:27:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:44 UTC