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

RE: New use case - RDFS/OWL related

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Tue, 8 Jun 2004 10:32:15 +0100
Message-ID: <E864E95CB35C1C46B72FEA0626A2E80803615357@0-mail-br1.hpl.hp.com>
To: Jim Hendler <hendler@cs.umd.edu>, public-rdf-dawg@w3.org

-------- Original Message --------
> From: Jim Hendler <>
> Date: 7 June 2004 17:57
> I'm not sure if this is a WD comment from an outsider (since I wasn't
> a member when the WD went out) or a suggestion from a new member (as
> I now am on the DAWG), but I would like to suggest that we add
> another use case to the document.  I think it is an important class
> of query that was completely ignored in the current draft (esp. as
> FOAF is rapidly becoming one of the most used Sem Web things, and
> this would refer to it).
>   In processing an RDFS schema or an OWL ontology that cites a term in
> another ontology, c.f.
>         me:Lilah a cyc:cat,
> I want to know what restrictions the cited graph has for this class
> -- i.e. in this example, I want to ask
>   cyc: for those triples of the form where the class definition
> includes a restriction (I'll spare you the gory details now, easy to
> generate) so I can process the triples appropriately, etc.

It seems to me that the underlying requirement is to be able to ask cyc: for
what it knows about this class.  It is a general, open question "tell me
about cyc:cat" or possibly "tell me about cyc:cat because I want to process
it" (that is, setting some context to the query).  The significant point is
that the client can't know exactly the graph pattern.  Here, there may be
several restrictions for the class.

We had queries of this kind in early email: it's a data oriented task but I
think has this similar characteristic of being an open "tell me about"


where the query is "tell me about" addressed to different KBs, resulting in
different information.  In each case, the query is an open question to the
KB and the requestor is then going to look at the graph returned (it has to
be a graph - not variable bindings).

Jim - have I understood you correctly?

This has got a bit lost in the document IMHO.  The nearest I can see is the
2.2 "Finding Information about Motorcycle Parts (Supply Chain Management)"
where the query gets back "Accelerator Cable" depends-on "Mounting Bracket"
and requires some screws.  This isn't an exact graph pattern match - it's a
"tell me about "Accelerator Cable" which also yields other stuff that the
server has been configured to return.

This "tell me about" query does not get reflected into the requirements
except weakly in 3.4 (Subgraph Results).  I see it as important though for
semantic web applications which want to do some further processing, here
process classes and properties, or wish to aggregate information from
different places and pass the assembled RDF graph to some other system.

(Aside: the text says "fuel management system" but the example is
"Accelerator Cable MK3" and "Mounting Bracket").

> I think it would be a valuable use case to publish as it is quite
> likely to come up quite often as, for example, FOAF and the like
> take-off, and people want to be able to process new data (i.e. go to
> the schema, see whether the new property "foaf:dnaCheckSum" we
> haven't seen before is inverse-functional) - I should note that I
> assume that the serialized graph of a number of important ontologies
> and schemas will be available on the Semantic Web (it is already
> happening for a number of them) and thus doing this by query of an
> RDF graph, rather than HTTP-GET of the document (which could be very
> large - the NCI ontology document, for example, is >25M) will be much
> more efficient.
> I believe it will be easy to make this a use case in the form the
> UC&R document uses (something like: A social network site is
> processing people's data based on foaf data that was dumped from a
> different social networking site.  It encounters a property it has
> not previously encountered so it queries a schema server to see
> whether this property has restrictions that would effect later
> processing of the data ...)
> I don't think this new use case would add any requirements or
> objectives, however I do think it makes a strong case for some of the
> existing ones (3.1, 3.4, 3.7, 4.2, 4.3) and is also an important one
> in that it helps to demonstrate that the DAWG's work is important for
> RDFS and OWL, not just RDF DBs.
>   -Jim H.

I don't see the relationship to 3.7 (Limited Datatype Support) but I do see
the relationship to 3.6 (Optional Match).

Received on Tuesday, 8 June 2004 05:36:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:27 UTC