Mapping ADQL - XQuery

[KevinBenson]

1.) Yes by default it is "any" for all backend implementations, since RI
currently says no subscripts and other node stuff like first(), position,
last().  It will be "any".  Which is okay.  And I am fine with it as well.

2.)
Just to clear up with a VOResource example is this and a little input:
  <relationship>
    <relationshipType>derived-from</relationshipType>
        <relatedResource ivo-id="ivo://AI">A</relatedResource>
  </relationship>
  <relationship>
    <relationshipType>derived-from</relationshipType>
        <relatedResource ivo-id="ivo://BI">B</relatedResource>
  </relationship>

The problem is I can query like this:
vr:relationship/vr:relatedResource = 'B' and
vr:relationship/vr:relatedResource/@ivo-id = 'ivo://AI'

 Now depending on how a relational db is mapped it will most likely do it
correctly and not return a resource.  For a xml document in a db such as a
xmldb mostly likely having the full vr:Resource in the db.  This will return
a Resource when it shouldn't because typically you will use vr:Resource as
the main node to query off (your context node).

My thoughts are to leave it like this and just consider it okay.

A couple of points:
*Yes I don't like it when our registry queries will return data differently
between our registries.  But in this case at least your getting extra
resources, so the user can look at it and just ignore it.  At least it's not
the other way around and not showing resources that we should.
*And as you say this will only happen on repeating elements (that either
have attributes or some other hiearchy of elements under it hence
complexTypes).  Which currently there are several like contributer,
publisher, and others doubtfull they will even thave the attributes on those
elements and rarely queried like above.  Only relationship would be one that
may be commonly queried on.  But in general at least you get the data back.


Cheers,
Kevin



-----Original Message-----
From: owner-registry at eso.org [mailto:owner-registry at eso.org]On Behalf Of
Tony Linde
Sent: 19 May 2005 20:47
To: 'Registry List'
Subject: Mapping ADQL - XQuery


Actually, the subject is more than simply mapping ADQL to XQuery but that is
how it came up (on the subway back from KICH!).

The point really is that we need, in the RI, to specify how identifying an
element in the ADQL WHERE clause that we use for simple searches translates
into identifying the appropriate element in the metadata for a resource. At
the moment, Ray and I can only think of this applying to repeat elements:
i.e., where we have <a><b><c/><c/><c/></a></b>, in the XPath name for
identifying an element we have '[/a/b/c]=99' but which of the c elements are
we checking for having the value 99? Ray implements it as 'any c = 99', but
equally valid is 'all c = 99' or 'first c = 99' etc.

It is necessary in the RI spec to mandate how this is handled so that the
same query sent to different registries returns the same information.

1. Personally, I'd vote for 'any c = 99' but let's hear other views.

The second place where this ambiguity occurs is '[/a/b/c]=99 AND
[/a/b/c at x]="Y"' (i.e. 'element c = 99' AND 'attribute x of element c has
value "Y"'): does this mean (if we assume 'any' as the answer to the above
question)
 'any element c = 99' AND 'any attribute x of any element c = "Y"' or
 'any element c = 99' AND 'the attribute x of the same element c = "Y"'

2. I'll pass on this one and defer to the experts.

Bear in mind that whatever we specify as the default, any agent accessing
the registry is free to use the XQuery interface of a registry which
supports that interface to ensure unambiguous querying.

Cheers,
Tony.
(PS: sorry wiki page not yet updated: cannot get uploads to work from hotel
room!!)

--
Tony Linde
Phone:  +44 (0)116 223 1292      Mobile: +44 (0)7753 603356
Fax:    +44 (0)116 252 3311      Email:  Tony.Linde at leicester.ac.uk
Skype:  callto:tonylinde (home)  callto:tonylinde2 (work)
Post:   Department of Physics & Astronomy, University of Leicester
        Leicester, UK   LE1 7RH
Web:    http://www.star.le.ac.uk/~ael

Project Manager, EuroVO VOTech   http://eurovotech.org
Programme Manager, AstroGrid     http://www.astrogrid.org
Co-Director,
 Leicester e-Science Centre      http://www.e-science.le.ac.uk/