- From: Howard Katz <howardk@fatdog.com>
- Date: Fri, 7 May 2004 06:21:18 -0700
- To: "Seaborne, Andy" <andy.seaborne@hp.com>, "Steve Harris" <S.W.Harris@ecs.soton.ac.uk>, "RDF Data Access Working Group" <public-rdf-dawg@w3.org>
> From: public-rdf-dawg-request@w3.org On Behalf Of Seaborne, Andy > Sent: Friday, May 07, 2004 1:58 AM [ snip ... ] > > > If a query includes some extension function (after 3.3), say a > > > function that takes a radius and the URIs for two geo-spatial > > > co-ordinate nodes and returns TRUE if one is in the radius of the > > > other. The complete graph used to answer that query is not > > > neccesarily known to the query engine - especailly if the function is > > > implemented at a lower level. Asking extension functions (for > > > example) to give the triples that it used to answer the question > > > seems unneccesarily onerous. > > If external functions are only filters, saying "accept" or "reject" (or > "undefined" probably), based on some bindings of the variables then there > does nto appear to be a problem. External functions should not be able to > bind variables. Why not? XQuery (among other languages; SQL comes to mind) allows this, and it seems to be a useful thing. The environment for example can pass in useful, named system constants. Here's a way of introducing the current date-time into the query. Here's a way of introducing the name of the current user. Since a variable can be bound to a sequence of arbitrary, heterogeneous items in XQuery, it can even be used in that environment to pass in a system-bound sequence of nodes and atomics of particular significance to seed the data-model instance. The RDF equivalent would be to pass in a pre-bound graph of triples. I'm sure smarter minds than me can find numerous interesting uses for this type of capability. >The current solution of the graph pattern does define a > part of the graph so it could be used to define a solution graph. > > If the external function returns a solution as a graph it gets > unecessarily complicated. In what way? Can you explain why you say this, Andy? > > That's really my main question to the group: are we designing > > a language in > > which specific and explicit knowledge of graph structure has > > to be embedded > > in the query? > > Going off the subject topic: > > On the wider point here, I think there are two issues here: locating parts > of the graph of interest and extracting information from the graph aroudn > those parts. > > Explicit graph structure is used to locate exactly which nodes are of > interest. Having located the nodes of interest, there is an extraction > process that gets data out of the graph - the results (there is than the > issue of presenting the results). > > If the query can only specify the exact shape of the results as > in variables > bound in graph patterns then the server can't return all it knows (the > motorcycle parts UC), only what the query has scoped. > > > It seems to me that we are or should be, but > > it's not clear to > > me that's been decided one way or another by the group. Has > > this question > > been answered to other people's satisfaction, or are we still > > in a bit of > > murky territory here? > > > > I don't see a contradiction in allowing external functions to > > do things > > under the hood and out of sight btw: they provide a needed > > escape mechanism > > for letting clever implementers get around the limits of having to be > > triple-wise explicit in the query. In me 'umble at any rate ... > > > > Howard > > Andy >
Received on Friday, 7 May 2004 09:19:54 UTC