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