- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Tue, 13 Apr 2004 10:56:38 +0300
- To: =?ISO-8859-1?Q? "ext_Jean-Fran=E7ois_Baget" ?= <jean-francois.baget@inrialpes.fr>
- Cc: <public-rdf-dawg@w3.org>
This appears to sync well with what I've been doing with RDFQ and URIQA concise bounded descriptions in our own environment (metadata driven services/content for the Forum Nokia web site). I certainly expect/hope that evaluation of queries expressed in RDF would benefit from the RDF and OWL MTs where possible/appropriate. Patrick On Apr 08, 2004, at 17:38, ext Jean-François Baget wrote: > > > Hi, > > Here are some notes and ideas about using RDFS and its semantics as the > kernel of a query language. Intentionally, there is not much here on > precise syntax for the language. Must it be all RDF/XML? The basic idea > is that the kernel of the query must be an RDFS document, and that the > answers to that basic query must be determined by RDFS semantics (or > else, we don't work on top of RDFS...) > > Elementary query > ---------------- > > DATA: > - The RDF Web (i.e. the set U = {D_1, ..., D_N} of all RDFS documents > that can be found on the web) > - The query > - a RDFS document Q > - A way to restrict U to one of its subsets (usefull for > efficiency > , thrust, ...) > > RESULT: A stream of answers > An answer is: > - A minimal subset A of the triples in the merge of U (or its > obtained restriction) that is semantically valid and such that Q is a > semantic consequence of A (in the sense of RDFS MT) > - A way to check where do these triples in A come from (because > thrust can be an issue) > - Since entailment can be seen as a matching[*], the mapping > from blanks in Q to terms of A (this is the proof of the entailment, > and > the way to retrieve the result for an SQL-like query). > > [*] More precisely a graph homomorphism, the minimal subset is the > homomorphic image, and the mapping the homomorphism itself. > > Building more complex queries > ----------------------------- > > Some things that we could do: > > FILTER THE STREAM OF ANSWERS > Data: the answers stream > By example by removing the answers where the image of a given blank in > the query does not satisfy a given predicate. > Result: a modified stream > > REORDER THE STREAM? > In that case, should wait for its end... > > FORMAT THE STREAM OF ANSWERS > - Extract the set of RDFS graphs from the stream (now we can > compose queries) > - Merge graphs > - View the result as triples, graphs, tables,... > > ... > > Other ideas are welcome... Where to put disjunction, negation in this > framework? > > > Example: Find the email address of "John Smith" > ----------------------------------------------- > > The query is: > > _john foaf:name "John Smith". > _john foaf:mbox _johnmail. > > The universe to explore is limited to the file where the user has its > addresses. > > Hopefully the stream of answers returns a single answer[*] > > _x345 foaf:name "John Smith" . > _x345 foaf:mbox john.smith@example.org . > > [*] May be an interesting feature would be to declare that a single > answer (up to equivalence) is expected, otherwise a warning could be > given. > > All triples come from the same source > > _john is mapped to _x345 and _johnmail is mapped to > john.smith@example.org > > We extract _x345 (i.e. the thing it is mappeded to), and obtain the > address. > > > I should write that properly, and look at more significant (difficult) > examples... > > > > Jean-François Baget > > INRIA Rhône-Alpes > jean-francois.baget@inrialpes.fr > Tel: 04 76 61 53 27 > > > > -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Tuesday, 13 April 2004 03:58:34 UTC