RE: New use case - RDFS/OWL related

Andy-
  I think you missed the intent of my message - I tried to be  clear 
that I was NOT talking about an open ended query -- I would not be 
going to CYC and saying tell me what you know about cats, I would be 
going to a graph and querying forthe bindings for a query something 
like this (I leave it in RDF/XML form for readability, but the quesry 
would be for those subgraphs of triples that match this


  <owl:class rdf:resource=":cat">
   <?CLASSTYPE>
     <owl:Restriction>
       <owl:onProperty ?PROP/>
       <?OWL ?REST>
     </owl:Restriction>
   </rdfs:subClassOf>
  </owl:class>

i.e. I don't say "tell me about cats" - I say
   Query the CYC graph for the pattern in which cat has a CLASSTYPE 
(subclassof or equivalentClass)
of a restriction class and return to me the names of what PROPerties 
the restriction is on, what OWLterm the restriction uses (AllValues, 
SomeValues, etc.) and what the RESTriction is.
   In practice I might do something different than this (perhaps 
multiple queries for specific combinations as I needed them), but in 
every case I am asking for specific properties of specific entities 
from an RDF graph - in my opinion, this capability is why I devoted 
so much of my past few years to making OWL an RDF language -- if I 
just wanted to query documents, I would have agreed that an XML 
syntax was sufficient -- but for linking and processing OWL, I want 
to use the URIs and the graph

  As far as 3.6 v. 3.7 goes, I was thinking of 3.7 for a couple of reasons:
  first, when cardinality is used the syntax of the query has to be 
able to handle the fact that the cardinalities are expressed using 
xsd:nonNegativeIntegers, and also some of the restrictions in OWL for 
datatype properties would include being able to query for the 
datatype -- maybe I was misinterpreting what 3.7 was intended for.
  As far as 3.6 goes, I guess I could use optional features in the 
above, I was thinking of multiple queries myself, but could go either 
way ...

  Hope that helps make things clearer -- if you want me to work out 
the informal example above as the actual triples, I'd be happy to, 
just didn't have the time so far.
   -JH



At 10:32 +0100 6/8/04, Seaborne, Andy wrote:
>-------- 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"
>question.
>
>http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JanMar/0022.html
>
>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).
>
>	Andy

-- 
Professor James Hendler			  http://www.cs.umd.edu/users/hendler
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  240-277-3388 (Cell)

Received on Tuesday, 8 June 2004 08:51:34 UTC