METS Archives -- December 2008 (#5)

Hi Rick,

An <area> element (or however we would like to call it) within smLinkLocator would allow to store area information with the relationship of two <div> elements. In other words: The <area> element would store particular metadata for the relationship. Metadata which describes where one div is placed within the other.

If one <div> element is representing an article and the other <div> element is representing a page, the <area> element could store the location of the chapter (from) within the page (to).

As this is a relationship between two <div> elements the <area> element has NOT exactly the same meaning as in the <fptr> pointing into a file. Maybe we shouldn’t call it <area> - it is more a location refinement.

This location refinement might be useful even for the hierarchical relationship between <div> elements stored in a <structMap>.

The reason why we can’t use the <area> element within the <fptr> element is, that this <area> element is manifestation specific. Currently there is no possibility to store this data in a non-manifestation specific way. In preservation environments, where manifestations will change over time, this information might get lost as we cannot regard the granularity of different manifestations are unchanging. An example for such a change in the manifestation’s granularity is a migration of several page based images into a single PDF. Such a migration would not allow to us to use an <area> element to point into the image itself.

As this information might be interesting, it must be stored somewhere else – e.g. in the smLinkLocator element as a location refinement.

Hope it became clearer what I meant.

However: Having a phone conference is a good idea. If we can find a time before Christmas, it would be great. Who will be able to set one up?

Ciao

markus

PS: Hope my other emails came through as well…. Received some “rejected replies”

-------- Original Message --------

Subject:	Re: [METS-BOARD] Revised smLinkGrp implementation.
Date:	Fri, 21 Nov 2008 14:07:16 -0700
From:	Rick Beaubien [log in to unmask]"><[log in to unmask]>
To:	METS Editorial Board [log in to unmask]"><[log in to unmask]>
References:	A[log in to unmask]"><[log in to unmask]> [log in to unmask]"><[log in to unmask]>







Regarding 3)  I confess that I don't (yet) understand your concerns and recommendations regarding a possible area element on the smLinkLocator.  The area element as defined in the context of a METS structMap must always be tied to a specific content file.  Each <fptr> under a div represents a separate manifestation of the div's content--and the purpose of the area can either be to isolate a particular part of  particular content file when it appears as an immediate child of <fptr>; or to identify either a particular integral content file or part of a particular content file when it appears as an immediate child of an fptr/par or fptr/seq (or fptr/par/seq or fptr/seq/par...).  To my mind the structLink section is not (at least not directly) concerned with manifestations of content at all--but just with non-hierarchical links between structural divisions.  It's up to the structMap to link these structural divisions with the content fil
es that manifest them as appropriate. Off-hand I think I would be pretty wary of introducing content into the structLink area.  But clearly I need to get a better grasp in the issues you perceive.



If I were to try to set up a conference call to discuss the structLink/extendedLink issues, who all on the board would be interested in participating in it?  Especially if we are going to have a board conference call before Christmas, it might be easiest to try to set something up at that time.  But I'm open to trying to do so before then if there's sufficient interest.