- From: Janne Saarela <janne.saarela@profium.com>
- Date: Tue, 16 Mar 2004 09:29:36 +0200
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
I think Andy's structuring of query steps makes a lot of sense. If possible, we could associate use cases to one or more steps of this structure. Clearly, JS-2 is related to the extract part and asks for syntactic sugar to do it without additional query primitives in locate part. Janne > Its seems to me that there are different stages in handling the query going > on here. A simple model I have used in the past is that a query has 3 > phases - locate, extract, present - which tries to capture the different > concerns. > > Locate: find the parts of the graph of interest (often, a set of resources) > This is the matching part. > > Extract: for each part that is interesting, collect information, such as > additional property values or local subgraphs. That is, this phase does not > effect the success or failure of the matching part but does contribute to > the overall information returned. Optional triples fit here. > > Present: concerned about how the results are handed back to the application > or requesting agent. For example, results sets or subgraphs of the original > graph. > > Applying this (rather simple) framework, the annotations Janne describes are > an issue for the extract phase, not the matching. The use of a second > query, driven by the first, is a common way an app has to do it in many of > the existing QLs but some allow option matching which includes the case of > adding annotations. > > Andy > > -------- Original Message -------- > >>From: Janne Saarela <> >>Date: 15 March 2004 07:50 >> >> >>>One could get the answer: >>> >>> { ?tune vcard:FN "L'amour de loin". >>> ?tune mb:genre ?genre. } => { <> answer (?genre) }. >>> >>>and the presentation information: >>> >>> { mn:genre rdfs:label ?label } => { <> answer (?label) }. >>> >>>separately. Is it a common case that the client asking >>>about an mb:genre property won't know how to display it? >> >>I agree that making separate queries will do the trick >>but it will make XSLT development trickier. >> >>What we need to build to our customers is query result >>visualisation using XSLT from RDF/XML to (X)HTML and >>other markup. >> >>For this purpose we've noticed that we need >>access to labels/comments from XSLT. If they are >>not explicitly requested in the original query, alternatives are: >> >>a) make other queries for them like you suggested which >>makes xslt more inefficient. >> >>b) include the natural language descriptions in the XSLT >>(replicating strings from RDFS to XSLT, not very nice) >> >>Therefore we had to introduce support for syntactic sugar >>ourselves to include rdfs:label and rdfs:comment to >>query results without query explicitly asking for them. >> >>Janne > > > > -- Janne Saarela <janne.saarela@profium.com> Profium, Lars Sonckin kaari 12, 02600 Espoo, Finland Tel. +358 (0)9 855 98 000 Fax. +358 (0)9 855 98 002 Mob. +358 (0)40 508 4767 Internet: http://www.profium.com
Received on Tuesday, 16 March 2004 02:29:42 UTC