[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [higgins-dev] [IdAS] filter language: XPath/SPARQL
- From: Greg Byrd <gbyrd@xxxxxxxx>
- Date: Mon, 21 Aug 2006 09:50:13 -0400
- Delivered-to: email@example.com
- User-agent: Thunderbird 188.8.131.52 (Windows/20060516)
SPARQL is meant to describe a query over an RDF graph, so you might get
several results back
Question 1: Is the filter expression intended to apply to (a) the
entire Context (i.e., the result of the filter should be the set of
DigitalSubjects that match), or (b) to a DigitalSubject (i.e., look at
each DigSub and add it to the list if the filter is true)?
I assume (a) (sort of), and that there is the capability in the filter
of narrowing the result set to only DigitalSubjects. I wouldn't expect
callers of getSubjects to have to add that to the filter though. I
assume the implementation would auto-add that (since the name of the API
implies that only subjects will be returned). So really, this is like
(b), but the provider's implementation details are different (provider
adds in a filter predicate to only allow DS's).
I don't know enough about SPARQL to know why (b) prevents ordering. My
guess is that at this point, you're the SPARQL expert, so you'll have to
clue us in on the particulars of the problems you see.
from the query. You can specify some criteria to order and limit the
results that you get back.
In the case I described as (b), the query is only being applied to a
subgraph that only contains
one DigitalSubject, so ordering has no meaning -- the ordering is
defined by how the search
algorithm visits the subjects, not by the query itself. Not really a
problem, just an observation.
I don't really understand how your (a) is different than (b). It seems
that you are essentially
specifying how a provider must implement the search (by adding an
filter). Can you explain how a filter would be written differently for
(a) with provider-inserted
DigSub filter vs. (b) where filter is written in the context of a
contains a single subject? (IMO, if (a) is not somehow more natural or
powerful than (b),
then (b) would be easier for a user to understand.)
Question 2: Is there a canonical RDF/XML representation...
OK, something like ".[type=... or @type=...]".
Another case is the representation of type. In Paul's example, we say
that urn:jim-sermersheim is a Person as follows:
But in the Primer, they tend to use the following:
<rdf:type rdf:resource="http://www.novell.com/jim#Person" />
In one case the type is an element, and in the other it's an attribute.
How would you use XPath in this case?
Assuming there's no canonical representation, one would have to OR the
two filters which match for those two examples.
While that solves this postalAddress problem, would you somehow force
Question 3: In the example, hasPostalAddress is a separate object.
XPath doesn't let us do this (effectively dereference a pointer to
another element) -- this is what prompted me to ask #3 (alternate
use this "in-line" approach? There might be a good reason for
as a separate object -- e.g., if multiple subjects share the same
address, then one could
change that address in one place, rather than in each subject. (And
what if the address
has an element that points back to a set of "inhabitants"? Can't be
in-lined because of its
If we allow the expressiveness of RDF to describe the Context, then I
we should then restrict the kinds of graphs that can be represented.
(I'm not saying
that you're advocating this, Jim.)