RE: JS-2: implicit inclusion of annotations

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

Received on Monday, 15 March 2004 10:10:22 UTC