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

Re: JS-2: implicit inclusion of annotations

From: Janne Saarela <janne.saarela@profium.com>
Date: Tue, 16 Mar 2004 09:29:36 +0200
Message-ID: <4056ACE0.6010109@profium.com>
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.


> 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 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

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