- From: Jim Hendler <hendler@cs.umd.edu>
- Date: Tue, 8 Jun 2004 10:20:49 -0400
- To: "Seaborne, Andy" <andy.seaborne@hp.com>, public-rdf-dawg@w3.org
At 15:05 +0100 6/8/04, Seaborne, Andy wrote: >-------- Original Message -------- >> From: Jim Hendler <mailto:hendler@cs.umd.edu> >> Date: 8 June 2004 13:51 [snip] > >I was assuming it was one query in which case the query does not know what >the nature (exact graph shape_ of the restriction. I read the intention as >"get the restriction whatever it is". Then, a request to get the >restriction has more than a fixed request because (example) there may be an >RDF list in there. A query of "get me the restriction for <expression>" has >the feature of the subgraph return that the exact shape of the graph is not >entirely in the > >> <owl:Restriction> >> <owl:onProperty ?PROP/> >> <?OWL ?REST> >> </owl:Restriction> > >So the restriction returned is that subgraph. Am I still missing the point >here? I don't understand - OWL has a very fixed form for defining restrictions (some of which could include subgraphs, some which couldn't) - I was purposely trying to make this example simple so was ignoring "oneOf" and the like -- what I'm really after is that it is pretty easy to query OWL and RDFS graphs for some useful information (for example, if you just want to know if a particular property is owl:inverseFunctional in FOAF). From a document-centric standpoint if I do an http-get on the class, I have to download a potentially huge file to see this one property. In a query-based approach I would go to a graph and simply look for a few triples --- I'd argue that in practice the few triples approach will have a better impact on your server than the one huge query approach which ties up your bandwidth and then my server for long periods of time (serializing CYC takes minutes on a lot of processors, so I sure don't want to do it multiple times for multiple properties) Just as a real example of using this - in the http://www.mindswap.org web site, we run a web portal off of RDF queries. When we use a new ontology we do correctly handle the inversefunctionals and etc by http-getting the ontology and serializing it into our triple store, and then a set of queries are used to generate things (and these queries take equivalentTo, inversefunctional and some other stuff into account). So, we only have to download the ontology once and then we do RDF queries against it -- I am thiking of this as a use case where I can avoid the download step, get the info I need from a remote query, and continue. I'd note that even without the "remote" part this is still a DAWG use case since, but I think that is the more interesting use. > >If you are prepared to make several queries, walking the graph and building >up the query each time then it is doable. I prefer the "get the subgraph >from this point" style which alos makes getting collections clear. > >I hope we can make this one query - having several small requests has >impacts on servers as well as issues of inconsistency in the presence of >updates (not bad in this case but in general the matter exists). > > Andy > >> 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. > >My mistake. I was thinking about 3.7 => supporting things like "?age < 43" > >> 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 10:21:03 UTC