Fw: holdings-schema proposal

Ray said:  "It is claimed that the schema cannot express
"volume 5, issue 2" as a flat value. (Why it can't isn't
clear to me...."

It's not clear to me either.

Can we allow unstructured string data in "alternativeEnumeration" and
"alternativeChronology" so that it can be used for simple flat display?


Janifer Gatenby
Pica ITC Consultancy
+31 71 5246  500 (tel)
+31 71 5223 119 (fax)
janifer.gatenby@pica.nl)
-------------Forwarded Message-----------------

From: INTERNET:rden@loc.gov, INTERNET:rden@loc.gov
To: ZIG, INTERNET:www-zig@w3.org

Date: 14/11/01 16:29

RE: holdings-schema proposal


There was a proposal presented at the October ZIG meeting to
change the holdings schema. See:
http://lcweb.loc.gov/z3950/agency/zig/meetings/uk2001/holdings.html

There was objection to the proposal, and we ended the
meeting with no clear path towards resolution. There was
agreement at the meeting to discuss this over the list, but
there has been little discussion and no progress towards
resolution (as far as I can tell).  I've recently been asked
(privately) to see if we can move the discussion along
towards consensus.

I would like to begin by trying to describe the problem in
my own words, partly to get a better understanding myself.

BibPart may have "child" bibParts, and this is represented
by recursion, that is, Bibpart  includes an element
childBibPart whose data type is BibPart.  Bibpart in
addition includes elements enumeration and chronology; these
two elements would occur within the child bibparts, as well
as the top level bib part.

Enumeration and chronology occur with each bibPart, and they
too are viewed as hierarchical, for example in the
enumeration  "volume 5, Issue 2",  "Issue 2" is subordinate
to "volume 5".  It is claimed that the schema cannot express
"volume 5, issue 2" as a flat value. (Why it can't isn't
clear to me. There doesn't seem to be any restriction on the
value, but let's assume you can't do it, for argument
sake.)  So the suggestion is that enumeration and
chronology  each be defined as individually recursive, to
allow children, thus to express the subordinate relation.
Thus every bibPart (top level and children) would have a
recursively defined enumeration and a recursively defined
chronology.

Those who oppose the proposal suggest that the recursive
definition of bibPart is sufficient recursion to recurse
these two elements (implicit recursion). In other word,
suppose there aren't really any child bib parts, but there
are "child" chronologies for the single bib part. You could
artificially recurse bibpart to effect the recursion.


That's my summary of the proposal and the two positions.  Is
this a reasonable interpretation?


If so, I have two observations/opinions:

1. I don't think that artificial recursion of bibPart (i.e.
implicit recursion) is a good thing. You shouldn't recurse
bibpart unless there is a child bibpart. If you do, you have
a semantic mess. Suppose we adopt these semantic and there
is a child bibpart:  how would you know whether the
recurring enumeration/chronology applies to the child or the
parent?

2. On the other hand, it seems like overkill to recurse
enumeration and/or chronology. Why can't they simply be made
repeatable? I.e. allow multiple occurences, where the
semantics of multiple occurences is that the N+1th occurence
is subordinate to the Nth.

Comments please!


--Ray



--
Ray Denenberg
Library of Congress
rden@loc.gov
202-707-5795






----------------------- Internet Header --------------------------------
Sender: www-zig-request@w3.org
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
by siaag2ae.compuserve.com (8.9.3/8.9.3/SUN-1.12) with ESMTP id KAA20127
for <100625.1240@COMPUSERVE.COM>; Wed, 14 Nov 2001 10:29:27 -0500 (EST)
Received: (from daemon@localhost)
by www19.w3.org (8.9.0/8.9.0) id KAA16994;
Wed, 14 Nov 2001 10:23:03 -0500 (EST)
Resent-Date: Wed, 14 Nov 2001 10:23:03 -0500 (EST)
Resent-Message-Id: <200111141523.KAA16994@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA16970
for <www-zig@www19.w3.org>; Wed, 14 Nov 2001 10:22:58 -0500 (EST)
Received: from sun8.loc.gov (sun8.loc.gov [140.147.249.48])
by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA02456
for <www-zig@w3.org>; Wed, 14 Nov 2001 10:22:59 -0500
Received: from rs8.loc.gov (rden.loc.gov [140.147.23.4])
by sun8.loc.gov (8.8.8+Sun/8.8.8) with ESMTP id KAA09044
for <www-zig@w3.org>; Wed, 14 Nov 2001 10:22:58 -0500 (EST)
Message-ID: <3BF28C54.B97F1DB4@rs8.loc.gov>
Date: Wed, 14 Nov 2001 10:23:00 -0500
From: Ray Denenberg <rden@loc.gov>
Reply-To: rden@loc.gov
Organization: Library of Congress
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: ZIG <www-zig@w3.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: holdings-schema proposal
Resent-From: www-zig@w3.org
X-Mailing-List: <www-zig@w3.org> archive/latest/538
X-Loop: www-zig@w3.org
Sender: www-zig-request@w3.org
Resent-Sender: www-zig-request@w3.org
Precedence: list
List-Id: <www-zig.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:www-zig-request@w3.org?subject=unsubscribe>

Received on Wednesday, 28 November 2001 09:54:09 UTC