| [higgins-dev] getDigitalSubjects semantics (was [IdAS] filter language: XPath/SPARQL) |
|
<referring to below>
>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? I assume in the (a jim) case, ordering semantics could still be applied (also, one can take advantage of indexes), whereas in the (b) case, it sounds like the implementation is going to visit each DS no matter what. I think this is all implementation details and we only need to worry about defining the semantics at the API level.
I think the semantics should be that this particular API only return DigitalSubjects, and that the user does not have to do anything special to make that happen.
Jim
>>> Greg Byrd <gbyrd@xxxxxxxx> 8/21/06 7:50 AM >>> >> >> ----- >> 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 _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |