Print

Print


Bronwyn,
Regarding an intermediate <fptr> between the <div> and the <seq> elements--you are absolutely correct, it it is needed.  Man, one would never know that I wrote the structMap section of the METS Primer!  What can I say, but (alas) I'm getting to an age where the details start to slip away fast....Thanks for the correction.

Rick

Bronwyn Lee wrote:
[log in to unmask]" type="cite">
Hi Markus, Rick
 
In the Australian Newspapers Digitisation Program we used a different approach for multi-page articles. We created a hierarchy of <div>s - a <div> for each of article, article-part (i.e. one for page the article occurs on) and article-zone (i.e. the zones, usually rectangles, drawn by the content analysis contractors around the headings, columns etc for each article). Each article-part <div> has an ORDER attribute. An example of a piece of structMap for a multipage article is inserted below - this is from the example at http://www.nla.gov.au/ndp/project_details/nla.news-issn18339719_19450913.xml which you can have a look at.
 
Rick, I re your example - I thought a <seq> element couldn't be a direct child of a <div> element? There has to be a <fptr> between a <div> and a <seq> doesn't there?
 
 
<mets:div ID="divarticle9" TYPE="article" DMDID="modsarticle9">
- <mets:div ID="divarticle9-1" TYPE="article-part" ORDER="1">
- <mets:fptr>
  <mets:area FILEID="nlaImageSeq-33386-b.tif" SHAPE="RECT" COORDS="2880,145,5270,7303" />
  </mets:fptr>
- <mets:fptr>
  <mets:area FILEID="nlaImageSeq-33386-b.xml" BETYPE="IDREF" BEGIN="ART9" />
  </mets:fptr>
- <mets:div ID="artzone9-1" TYPE="article-zone">
- <mets:fptr>
  <mets:area FILEID="nlaImageSeq-33386-b.tif" SHAPE="RECT" COORDS="2885,145,5268,433" />
  </mets:fptr>
- <mets:fptr>
  <mets:area FILEID="nlaImageSeq-33386-b.xml" BETYPE="IDREF" BEGIN="ZONE9-1" />
  </mets:fptr>
  </mets:div>
- <mets:div ID="artzone9-2" TYPE="article-zone">
- <mets:fptr>
  <mets:area FILEID="nlaImageSeq-33386-b.tif" SHAPE="RECT" COORDS="2880,430,5268,685" />
  </mets:fptr>
- <mets:fptr>
  <mets:area FILEID="nlaImageSeq-33386-b.xml" BETYPE="IDREF" BEGIN="ZONE9-2" />
  </mets:fptr>
  </mets:div>
- <mets:div ID="artzone9-3" TYPE="article-zone">
- <mets:fptr>
  <mets:area FILEID="nlaImageSeq-33386-b.tif" SHAPE="RECT" COORDS="2895,662,3690,6835" />
  </mets:fptr>
- <mets:fptr>
  <mets:area FILEID="nlaImageSeq-33386-b.xml" BETYPE="IDREF" BEGIN="ZONE9-3" />
  </mets:fptr>
  </mets:div>
- <mets:div ID="artzone9-4" TYPE="article-zone">
- <mets:fptr>
  <mets:area FILEID="nlaImageSeq-33386-b.tif" SHAPE="RECT" COORDS="3685,680,4468,7303" />
  </mets:fptr>
- <mets:fptr>
  <mets:area FILEID="nlaImageSeq-33386-b.xml" BETYPE="IDREF" BEGIN="ZONE9-4" />
  </mets:fptr>
  </mets:div>
- <mets:div ID="artzone9-5" TYPE="article-zone">
- <mets:fptr>
  <mets:area FILEID="nlaImageSeq-33386-b.tif" SHAPE="RECT" COORDS="4468,680,5270,7303" />
  </mets:fptr>
- <mets:fptr>
  <mets:area FILEID="nlaImageSeq-33386-b.xml" BETYPE="IDREF" BEGIN="ZONE9-5" />
  </mets:fptr>
  </mets:div>
  </mets:div>
- <mets:div ID="divarticle9-2" TYPE="article-part" ORDER="2">
- <mets:fptr>
  <mets:area FILEID="nlaImageSeq-33387-b.tif" SHAPE="RECT" COORDS="246,120,1037,4557" />
  </mets:fptr>
- <mets:fptr>
  <mets:area FILEID="nlaImageSeq-33387-b.xml" BETYPE="IDREF" BEGIN="ART9" />
  </mets:fptr>
- <mets:div ID="artzone9-6" TYPE="article-zone">
- <mets:fptr>
  <mets:area FILEID="nlaImageSeq-33387-b.tif" SHAPE="RECT" COORDS="246,120,1037,4557" />
  </mets:fptr>
- <mets:fptr>
  <mets:area FILEID="nlaImageSeq-33387-b.xml" BETYPE="IDREF" BEGIN="ZONE9-6" />
  </mets:fptr>
  </mets:div>
  </mets:div>
  </mets:div>
 

Bronwyn Lee
Business Analyst, IT Division
National Library of Australia
[log in to unmask]

Australian Newspapers beta search & delivery system http://ndpbeta.nla.gov.au
Australian Newspapers Digitisation Program information http://www.nla.gov.au/ndp
 

From: Metadata Encoding and Transmission Standard [mailto:[log in to unmask]] On Behalf Of Rick Beaubien
Sent: Saturday, 30 August 2008 2:30 AM
To: [log in to unmask]
Subject: Re: [METS] ORDER attribute for <smLink> element

Hi Markus,

I think it might be useful to see what what your structMap (structMaps?) look like.  In particular, could you provide an example of what the <div> for an article would look like--including its associated <fptr> and/or <area> elements?

I guess I am wondering why a <seq> element under the <div> representing an article wouldn't cover your need--and why an <smLink> is needed at all.  For example:

<div LABEL="article20">
     <seq>
          <area FILEID="ImageForPage20" SHAPE="RECT" COORDS="x1,y1,x2,y2">
          <area FILEID="ImageForPage19" SHAPE="RECT" COORDS="x1,y1,x2,y2">
     </seq>
<div>

If you really need to establish a link between the <div> elements representing pages and and the div elements representing articles  (as well you may), as opposed to just between the div representing an article and the sequence and areas of the page images needed to manifest the article, then I am wondering if maybe a slightly more elaborate (and precise) mechanism than just an smLink ORDER attribute is indicated:  possibly an <smLinkSeq> element that could link one div to a sequential set of other divs?:

<structLink>
     <smLinkSeq xlink:from="article20">
          <smLink xlink:from="article20" xlink:to="page20">
          <xmLink xlink:from="article20" xlink:to="page19">
     </smLinkSeq>
</structLink>

Mostly, I think it would be helpful to get a clearer understanding of how the smLinks would be used and what they would accomplish beyond what can be accomplished with the <div>/<seq>/<area> mechanism.

Best,
Rick

Enders, Markus wrote:
[log in to unmask]" type="cite">

Hi everybody,

I would like to see a small extension for the smLink element to store the order of those links. An ORDER attribute would be very helpful to store the order explicitly. E.g. <smlink ID=”xxx” ORDER=”123” xlink:from=”…” xlink:to=”…”/>

The use case for this is modelling a newspaper using METS. Our current model uses two different structures – one reflecting the logical view of sections, articles and illustrations – the other one reflecting the physical view with its pages, columns and page areas.

The <smLink> is used to store the relationship between the logical entity (the article) and the page – or to be more exact even the column and page area.

The <div> element of the page has an optional ORDER attribute. The value of this attribute stores the order of <div> elements within its parent element. This allows the browsing of pages in the right order. Unfortunately the order of pages might not necessarily be the order the article is printed.

Some newpapers have a “second” front page on the back. In the UK this is usually covered with Sport news. So the articles are starting on the last page but are continued on some of the previous pages.

As the ORDER attribute for the page really covers the order of pages within the issue, the only possible way to store this order is the <smLink> which represents the relationship. For the time being the order of <smLink> elements within the <structLink> section might represent the correct order – e.g.

<structLink>

      <smLink xlink:from=”article20” xlink:to=”page20”/>

      <smLink xlink:from=”article20” xlink:to=”page19”/>

</structLink>

A much better way and more consistent with the ORDER attribute of the <div> element would be the usage of an additional ORDER attribute for <smLink>.

For the purpose described above I don’t see any usage of the ORDERLABEL attribute.

Ciao
Markus

**************************************************************************
 
Experience the British Library online at www.bl.uk
 
The British Library’s new interactive Annual Report and Accounts 2007/08 : www.bl.uk/knowledge
 
Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook
 
The Library's St Pancras site is WiFi - enabled
 
*************************************************************************
 
The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the [log in to unmask] : The contents of this e-mail must not be disclosed or copied without the sender's consent.
 
The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author.
 
*************************************************************************
 

-- 
Rick Beaubien
Software Engineer, Research and Development
U.C. Berkeley Library

Contact information:
505-466-6630


88 Herrada Rd
Santa Fe, NM 87508

-- 
Rick Beaubien
Software Engineer, Research and Development
U.C. Berkeley Library

Contact information:
505-466-6630

88 Herrada Rd
Santa Fe, NM 87508