fromUnionQuery

My opinion on this issue is that the query language should allow
construction of whatever RDF dataset design we give.

This would be in addition to the SPARQL protocol. WSDL1/2 may be a
solution for some people but I can't see using it anytime soon.

I want to construct the dataset in two ways

1. inside the programming API
  This would be used inside running programs and for implementing
  web interfaces where the URIs given of the graphs can be checked
  for denial of service, size, etc. issues before loading into the
  system.

2. inside the query language.
  This would be when "just running" a query, such as a stock one
  ("this one gives you the answer") against a well known or standard
  data source.  At this point you trust the query. 

  It also allows easy chaining of queries, using an RDF/XML output of
  one query via http protocol made with CONSTRUCT/DESCRIBE as a data
  source for later queries.

3. on the command line
  Either of #1 and #2 enable SPARQL to work on the (unix) command
  line allowing RDF to enter the processing data pipeline but #2 also
  allows easier data integration (fan-in) which is rather more clumsy
  to do with lots of -d URI command parameters.  This is a weaker
  reason I admit.

I have implemented and am already all of #1, #2 and #3

Without the WITH/FROM equivalent it makes the language much less
interesting and useful to me and rather too statically designed for
what I've always thought of as a dynamic web query language - working
on demand.

I'm not stuck on the names WITH/FROM, or even the background/named
graph split.  I'm happy with just a set of named graphs.

Dave

Received on Thursday, 7 April 2005 15:34:30 UTC