Re: JS-2: implicit inclusion of annotations

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