Date:         Tue, 17 Dec 2002 11:22:10 -0800
Reply-To:     Metadata Encoding and Transmission Standard
              <[log in to unmask]>
Sender:       Metadata Encoding and Transmission Standard
              <[log in to unmask]>
From:         Reagan Moore <[log in to unmask]>
Subject:      Re: annotations
Comments: To: Metadata Encoding and Transmission Standard <[log in to unmask]>
In-Reply-To:  <[log in to unmask]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

We have followed this approach in the SDSC Storage Resource Broker.
The system manages a logical name space that is used to implement
global persistent identifiers for the digital entities that are
registered into the collection.  We manage mappings on the logical
name space.  Each mapping is characterized by an associated set of
attributes.  Examples are:

- mapping from collection-owned data to user access control lists.
ACLs are specified for each digital entity.
- mapping from logical name space to physical files.  A one logical
name to many physical file names mapping is used to support
replication.
- mapping from logical name space to annotations that are
characterized by annotator, time of annotation.

Annotations are both the associated attributes required for the
mapping to the digital entity, and the document that includes the
annotation text.

Reagan Moore


>At 09:56 AM 12/17/2002 -0700, you wrote:
>>Are you looking at w3c's Annotea project in this context?
>>(http://www.w3.org/2001/Annotea/). It might at least provide a model for
>>dealing with some of these complexities.
>
>Somewhat, although I wonder if we can abandon the notion of a separate
>annotation server in favor of annotations as just another form of document.
>Then each annotation would be its own METS document and would identify
>one or more additional METS documents/subdocuments as the relevant
>content.  Then whatever mechanisms the repository already supports for
>user authentication and access control would be available for the annotations.
>
>Just speculating wildly here, of course.  We haven't even spec'ed this out,
>let alone built it.
>
>>Peter
>>
>>Peter Binkley
>>Digital Initiatives Technology Librarian
>>Information Technology Services
>>4-30 Cameron Library
>>University of Alberta Libraries
>>Edmonton, Alberta
>>Canada T6G 2J8
>>Phone: (780) 492-3743
>>Fax: (780) 492-9243
>>e-mail: [log in to unmask]
>>
>>
>>
>>  > -----Original Message-----
>>  > From: Jerome McDonough [mailto:[log in to unmask]]
>>  > Sent: Tuesday, December 17, 2002 7:13 AM
>>  > To: [log in to unmask]
>>  > Subject: Re: [METS] annotations
>>  >
>>  >
>>  > At 11:37 AM 12/17/2002 +0100, you wrote:
>>  > >Has anyone experience using annotation with METS, so that people are
>>  > >able to append information or annotations directly to a document so
>>  > >that otherswho are interested would have a way to attach/view those
>>  > >comments precisely at the point within a document to which they are
>>  > >relevant. What is the easiest way to do so when using METS ?
>>  >
>>  > We haven't actually done this yet, but we are considering it
>>  > for a project at the NYU Medical School. Our general idea is
>>  > to create a 'medical practitioner's notebook' which allow
>>  > students and faculty (and hopefully
>>  > alumni) to not only combine medical DL resources in ways they
>>  > find intuitive but to also add their own annotations and
>>  > commentary on resources.  The general approach is fairly
>>  > obvious; annotations can be considered as a form of
>>  > descriptive metadata for a resource.  To allow an annotation
>>  > to be associated with part of a work, you need to create a
>>  > METS object with a structural map which identifies the
>>  > described section as a discrete <div>, and then link that
>>  > <div> to a descriptive metadata section containing the
>>  > annotation.  From the general approach, however, you quickly
>>  > get into a variety of complexities: enabling some annotations
>>  > to be shared while others aren't, where best to store METS
>>  > documents containing a user's annotations, how to provide a
>>  > front-end to such a facility which makes sense to users, how
>>  > to edit the structural maps of existing METS documents to
>>  > allow the insertion of annotation <div>s while not
>>  > compromising the original structure, etc.  One of our biggest
>>  > difficulties will revolve around versioning and preservation.
>>  >   If we have
>>  > a video instructing people in a
>>  > particular surgical procedure, and that procedure changes in
>>  > five years (along with the training video), we'll need to
>>  > alert anyone who has 'collected' and annotated the original
>>  > video that it documents an outdated procedure; however, we'll
>>  > probably also need to allow access to the original if we're
>>  > going to enable faculty's annotations to survive.  The DSpace
>>  > repository software developed at MIT has much of the low
>>  > level functionality necessary for tracing object
>>  > history/versions and may form the basis for some of our work;
>>  > the question is how best to provide a new front end into that
>>  > system that alerts users to significant events in a DL
>>  > object's life history and which enables the sort of
>>  > organization and annotation of resources within DSpace that
>>  > we'd like to provide to faculty and students.
>>  >
>>  > I will admit we are in *very* early days in thinking about
>>  > this and would be interested in hearing about others who are
>>  > contemplating using METS as a 'client side' tool in this
>>  > manner and what approaches folks may be taking.
>>  >
>>  >
>>  >
>>  > Jerome McDonough
>>  > Digital Library Development Team Leader
>>  > Elmer Bobst Library, New York University
>>  > 70 Washington Square South, 8th Floor
>>  > New York, NY 10012
>>  > [log in to unmask]
>>  > (212) 998-2425
>>  >
>
>Jerome McDonough
>Digital Library Development Team Leader
>Elmer Bobst Library, New York University
>70 Washington Square South, 8th Floor
>New York, NY 10012
>[log in to unmask]
>(212) 998-2425