On Thu, 8 Jul 2010 07:52:29 -0400, Ray Denenberg, Library of Congress wrote
> Ed, although I take Peter's point and probably agree - that
> "container" is probably a more semantically appropriate term than
> "element" for its proposed use - I don't recall that anyone even
> brought up that point in the discussion, there was an entirely
> different reason altogether: that "element" is too suggestive of xml,
> and "container" is more neutral. And though I also take Mikes point

Container is not neutral. Nor is element. Element is about membership.
Container is about possession.

> that "element" can mean whatever you want it to, when someone says
> "name and date in the same element" that suggests xml to too many
> people. Your shoe example is more complicated that anything we are
> trying to represent in CQL. There won't be containters within
> containters. --Ray

Of course there are containers within containers--- unless you adopt MY
semantics for container as a specific kind of element, e.g. with no
children--- and we've had them for YEARS and YEARS (thinking CAPS, GILS, DIF,
Dublin Core, ISO 19115 etc.)... We don't, I think, want to try flatten the
world as we did back in Z (forced by OIDs to avoid horrible acrobatics)---
where we even had "problems" with repeating elements.

With elements/containers like word, line, sentence, paragraph, section,
chapter, ... you have containers that contain containers--- even "worse" you
have overlap since a line can contain multiple sentences and a sentence can
span one or more lines.

And we want to search these.. and with all kinds of structure don't we?

As soon as fields have sub-fields.. we have elements within elements..
containers within containers like Matryoshka dolls.

We can talk about paths or ways of describing elements, either generically,
"name" or specific "person/name" (the name of a person).. But we also want to
talk about terms being in the same ..... (insert the word "container" or ???
for the leafs without sub-elements/containers or ..).


>
> -----Original Message-----
> From: SRU (Search and Retrieve Via URL) Implementors
> [mailto:[log in to unmask]] On Behalf Of Edward C. Zimmermann
> Sent: Thursday, July 08, 2010 4:15 AM To: [log in to unmask]
> Subject: Re: CQL example for prox/unit=
>
> On Tue, 6 Jul 2010 16:52:26 +0000, Peter Noerr wrote
> > I have only one question:
> >
> > Why on earth would one prefer to define an "element" as a "thing which
> > contains other things", and "container" as a "thing which
>
> I would suggest that to ask about information "in the same
> container" if "container" means element makes no sense..
>
> Elements can be nested.. What's
> <parent><child><grandchild> .. </grandchild></child></parent> ?
>
> Is the value of grandchild also contained in child and parent?
>
> And to the other extreme we have empty elements.. <empty></empty>
> (or <empty /> )
>
> In SGML/XML an element can have many or no children.
>
> We can talk about atomic elements as an element that has no children
> but may or may not have content--- but we, of course, are only
> interested in elements with content..
>
> In SGML/XML we have "content" in the value of the element and its attribute
> values:
> <element attribute="attribute value">Element value</element>
>
> Now.. We should be interested in information structures even more
> abstract than SGML/XML (e.g. overlaps etc.) and so things can get
> even more twisted..
>
> How would I ask the question that gives me the answer "Edward Zimmermann"
> below:
>
> <person><name>Edward
> Zimmermann</name><address><street>Leopoldstrasse
> </street><city>Munich</city></address> </person>
>
> In the same name instance? But what if I don't know that the
> "container" is called "name"?
>
> In above are not Zimmermann and Leopoldstrasse contained in the same
> person element instance?
>
> How should I distinguish these two? Zimmermann is contained in name
> and Leopoldstrasse is contained in street, street is a child of
> address and both address and name are siblings of person..
>
> These are the kind of questions we ask all the time.. right? Give me
> the Zimmermanns on Leopoldstrasse in Munich. Give me cookbook's
> written by Schiller.. Tell me which books were edited by Johann
> Wolfgang Goethe?
>
> Sure if we know the questions ahead of time we can structure (or
> transform) a database with the structure to make such queries easy
> (and flat).. But then the next questions which don't fit that
> structure?
>
> And when we start to talk about heterogeneous data.. that is when
> the user is not even 100% on the structure they can't ask for
> "street" or "person" but they'd like to still ask the question.. By
> talking about anonymous containers.. etc. Its possible..
>
> > contains no other things" when this is *exactly* the reverse of their
> > normal English usage? Is there a perverse desire here to make things
> > (pun intended) as confusing as possible?
>
> Not really.. Think about a shoe shop.. They sell pairs of shoes
> stored in boxes.. and that box of shoes is stored on a shelf and
> that shelf has an address. Is the container the room where these
> shelves are? The shelf? The level in the shelf? Or the shoe box?
>
> In this model.. The elements are the shop, the room, the shelves,
> the specific shelf, the box.. we have a path of elements to define
> an address to find the container which contains a specific pair of
> shoes.. When we talk here of container we mean the box (which
> contains a pair of shoes).. even if the box is contained in the
> shelf, in the room, in the shop, in the house, ...
>
> >
> > Peter Noerr
> >
> > > -----Original Message-----
> > > From: SRU (Search and Retrieve Via URL) Implementors
> [mailto:[log in to unmask]] On Behalf Of Edward
> > > C. Zimmermann
> > > Sent: Saturday, July 03, 2010 4:07 PM
> > > To: [log in to unmask]
> > > Subject: Re: CQL example for prox/unit=
> > >
> > > 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
> [UTF-8?][UTF-8?]‘author’ that
> > > contains indexes [UTF-8?][UTF-8?]‘name’ and
[UTF-8?][UTF-8?]‘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
>
> --
>
> Edward C. Zimmermann, NONMONOTONIC LAB
> Basis Systeme netzwerk, Munich Ges. des buergerl. Rechts
http://www.nonmonotonic.net


--

Edward C. Zimmermann, NONMONOTONIC LAB
Basis Systeme netzwerk, Munich Ges. des buergerl. Rechts
Umsatz-St-ID: DE130492967