[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] [IdAS] filter language: XPath/SPARQL


-----
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)?

<skip>
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.
SPARQL is meant to describe a query over an RDF graph, so you might get several results back
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 additional DigitalSubject
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 subdocument/subgraph that
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...
<skip>
Another case is the representation of type. In Paul's example, we say
that urn:jim-sermersheim is a Person as follows:

<rdf:Description rdf:about="urn:jim-sermersheim">
      ...
      <rdf:type>
            <rdf:Description rdf:about="&jim;Person>
      </rdf:type>
</rdf:Description>

But in the Primer, they tend to use the following:

<rdf:Description rdf:about="urn:jim-sermersheim">
      ...
      <rdf:type rdf:resource="http://www.novell.com/jim#Person"; />
</rdf:Description>


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.
OK, something like ".[type=... or @type=...]".
-----
Question 3: In the example, hasPostalAddress is a separate object.
<skip>
XPath doesn't let us do this (effectively dereference a pointer to
another element) -- this is what prompted me to ask #3 (alternate
representations) in
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg00583.html

While that solves this postalAddress problem, would you somehow force providers to
use this "in-line" approach? There might be a good reason for representing postalAddress
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
circular structure.)

If we allow the expressiveness of RDF to describe the Context, then I don't believe
we should then restrict the kinds of graphs that can be represented. (I'm not saying
that you're advocating this, Jim.)

...Greg