Re: holdings-schema proposal

It's already available in ChildEnumChronology.

j.

----- Original Message ----- 
From: "Janifer Gatenby" <janifer@wanadoo.fr>
To: "Ray Denenberg" <rden@loc.gov>; <www-zig@w3.org>
Cc: "Janifer Gatenby" <janifer.gatenby@pica.nl>
Sent: Wednesday, November 28, 2001 9:40 AM
Subject: 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 11:08:00 UTC