LISTSERV mailing list manager LISTSERV 16.0

Help for ZNG Archives


ZNG Archives

ZNG Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

ZNG Home

ZNG Home

ZNG  July 2010

ZNG July 2010

Subject:

Re: CQL example for prox/unit=

From:

"Ray Denenberg, Library of Congress" <[log in to unmask]>

Reply-To:

SRU (Search and Retrieve Via URL) Implementors

Date:

Thu, 8 Jul 2010 07:52:29 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (179 lines)

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 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

-----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?]‘author’ that
> > contains indexes [UTF-8?]‘name’ and [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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

July 2017
October 2016
July 2016
August 2014
February 2014
December 2013
November 2013
October 2013
February 2013
January 2013
October 2012
August 2012
April 2012
January 2012
October 2011
May 2011
April 2011
November 2010
October 2010
September 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
October 2009
September 2009
August 2009
July 2009
May 2009
April 2009
March 2009
February 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager