[tdwg-tapir] TAPIR searches and entities
roger at tdwg.org
Sat Apr 8 00:39:58 CEST 2006
I am going to be contoversial and say the join should not be supported at
all! The client should do the join themselves. They should get a set of
nicely defined determination objects (on the basis of a query of their
literal properties == easy stuff) and then go back and get the specimen
objects (on the basis of GUIDS == easy stuff) if they want more information.
The determination objects may contain LSIDs of specimens and taxon concepts
or names that are held by different data sources so how can the data source
make the join? Isn't this nature of the system we are trying to build? Some
day down the line a grid service may do the join for the client and cleverly
cache stuff from different data sources but that is a story for another
Also this is an incredible difficult problem to solve so apply Brave Sir
Robin's rule - run away!
It will all be fun to talk about at the meeting but I suggest we hang off
discussions on the list just now as some people will be in transit.
Looking forward to seeing attendees next week and hope that we can feed
discussions out to the email list as they happen - so the rest of you guys
can join in.
All the best,
On 07/04/06, Steven Perry <smperry at ku.edu> wrote:
> Hi Markus,
> This is analogous to the example that Rob and I showed at the Madrid
> TAPIR meeting with relationships between records representing people and
> records representing the department(s) they work in. The issue in both
> cases is that, with complicated data of multiple types, global concepts
> don't always provide enough information for one to answer the kinds of
> queries they might like. To do queries like these, its our feeling that
> you have to know information about the different types of objects whose
> relationships you want to examine (in other words you have to know the
> domain of each property).
> Just as an aside, most triple stores that are implemented over databases
> process queries using the second approach you outlined below (repeated
> self joins on the triple table). The beauty of this approach is that,
> with minor modifications, you have the ability to represent combinations
> of ANDs and ORs which allow you to distinguish between mandatory and
> optional match conditions independently of what you want to return from
> the query.
> I'm also looking forward to talking about this and other issues in
> Edinburgh; see you next week.
> Döring, Markus wrote:
> > Hello,
> > I had a talk with Gregor and the others this week to find out whether
> TAPIR is suitable for SDD. Apart from the known recusive issue we were
> concerned about one major search problem I would like to introduce you to:
> > Imagine a simple concept "ontology" with a specimen linked to
> identifications with a taxon-name and an identifier (person).
> > If I want to do a combined search on the identifier AND the taxon name I
> actually have 2 ways of asking the query.
> > 1) use the same identification object to do the AND. In SQL this would
> > SELECT * FROM specimen s JOIN identification i ON xxx WHERE i.taxon_name= "Abies alba" AND
> > 2) dont require the identifier to have done the identification of the
> required name, but to be an independent constraint. In SQL you would use an
> alias of that table:
> > SELECT * FROM specimen s JOIN identification i1 ON xxx JOIN
> identification i2 ON xxx WHERE i1.taxon_name = "Abies alba" AND
> > This gives different results.
> > And it is a common query in SDD when searching on characters.
> > As far as I can see TAPIR cannot handle this, as a TAPIR request doesnt
> know about the relations between concept. The entities, classes whatever you
> would like to call it. A loose list of independent concepts really doesnt
> seem to work. We might need to know about the class relations/multiplicity
> at least on a high level. In general this could be taken from an XML Schema
> as well as OWL, RDFS or alike.
> > Or we could prescribe a TAPIR service what to do in such cases. If a
> complex AND query is received we could prescribe to resolve that query in
> way #1 (i think its the more common intention). But then noone would be able
> to ask questions of type2.
> > Maybe we could discuss this further in the TAG meeting, Session 4:
> Integration of Existing Technologies with a Core Ontology?
> > I do not have an answer yet to that question, but I wanted to spread the
> problem before the TAG meeting.
> > Looking forward to meet you all in Edinburgh,
> > Markus
> > _______________________________________________
> > tdwg-tapir mailing list
> > tdwg-tapir at lists.tdwg.org
> > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
Taxonomic Databases Working Group
roger at tdwg.org
+44 1578 722782
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tdwg-tag