Ray, I'm actually quite pleased. I feel almost as if someone has been
listening! There are, however, just a few points still that need to be voiced..
On Sat, 3 Jul 2010 15:40:52 +0100, Mike Taylor wrote
> Surely "container" here means EXACTLY the same thing as "element",
> i.e. whatever you want it to mean?
>
In SGML containers are called elements. When we want to distinguish between an
element and the containers it contains we can talk about container thus they
are, in semantic use, not always the same. See below.. (my argument is that
they have things backwards).
On Fri, 2 Jul 2010 17:55:02 -0400, Ray Denenberg wrote
> Peter, that's an example of structured proximity searching and that
> has been abandoned in the OASIS CQL spec, the most recent draft of
> which is at http://www.loc.gov/standards/sru/oasis/current/cql.doc
> which I recommend that you look at, because it clarifies (and
> simplifies) proximity.
On Sat, 3 Jul 2010 09:31:40 -0400, Ray Denenberg wrote
> Just want to add this. The problem isn't so much in saying "find A
> and B in the same element", the problem is when the distance is
> greater than zero as in "find A and B separated by two elements".
> In the OASIS spec, the notion of element is discarded and the more
> abstract notion of "container" is defined, and you can "find A and B
I would argue that the predicate "container" should be used as a name for a
specific kind of element, namely atomic containers, viz. containers with no
sub-containers (indexes). An element here would be a container when it has no
sub-elements. In a typical flat format such as common to Z applications the
fields are elements and containers..
> in the same container" (with no notion of finding A and B separated
> by, say, two containers). --Ray
Correct. Since in XML and many other models there is no order one can't talk
about distance. The only distance one can talk about is bytes according to how
the information was marked-up but only if the information was marked-up.
The doc: "A container is a structure containing one or more indexes. For
example the server may support a container whose name is ‘author’ that
contains indexes ‘name’ and ‘date’. In that case the server would support a
query (see example) to find an author with a specific name and date. (This
is contrasted with a Boolean query which may return undesired results because
they have multiple authors, some of which have the desired name but the wrong
date and others the specified date but the wrong name.) The server should list
supported containers in its Explain file, and for each container, the indexes
that it contains."
Exactly. One has here named sub-paths author/name and author/date but also
the anonymous path "in the same container". I, however, would swap around the
semantics and view "container" as the lowest node and element any .. example:
<book>
<title>Re: CQL example for prox/unit=</title>
<author>
<name>Edward C. Zimmermann</name>
<date>11 Feb 2000</date>
</author>
<edition>2nd</edition>
<date>3 July 2010</date>
</book>
The element book contains title, author, edition, date etc.
In the "same container" would however mean exclusively the lowest node (leaf).
Containers should have no sub-elements
Edward and Zimmermann are in the same container (book/author/name>)
Edward and CQL are not in the same container even if, per your semantics the
container author as two sub-elements.. whence the same container would be the
same "author" container.
In my IB engine the semantics for "in the same container" only applies to the
lowest.. e.g. bookauthor/name instance or book/author/date instance..
If I want to search for Edward and SQL in the same book then I search for
it by name WITHIN:book or explicitly in path WITHIN:\book (I use \ for / as
/ is used to denote fields). That is: elements (and paths).
In my above example: 2000, Zimmermann are in the same author.. they are also
within the same book.. CQL and Zimmermann are within the same book but not
within the same author. etc... 2010 and July are in the same date. July and
2000 are not in the same date but are in the same book.. etc.
http://www.ibu.de/RelationalHierarchicalIR
http://www.ibu.de/IB_Query_Fields
--
Edward C. Zimmermann, NONMONOTONIC LAB
Basis Systeme netzwerk, Munich Ges. des buergerl. Rechts
http://www.nonmonotonic.net
Umsatz-St-ID: DE130492967
