Subject: [CODE4LIB] Duke metadata tool project

From: Will Sexton <[email-masked]>
Date: Tue, 17 Feb 2009 11:10:47 -0500

I posted here early in the winter on Duke's plans to develop a software 
tool to support metadata creation.  Our project has moved forward with 
the hiring of two programmers and an intensive phase of analysis and 
design.  We want to share our progress as we go, so I've composed a post 
with some of our design documents at

http://library.duke.edu/blogs/digital-collections/2009/02/13/on-the-trident-project-part-1-architecture/

As always we welcome feedback from the code4lib community.  Regrettably, 
we'll not send anyone to the conference next week, but I thought I would 
use this very nearly calm moment  to report on our progress and invite 
discussion.

Best,

Will
--
Will Sexton
Metadata Analyst / Programmer
Duke University Libraries

---

From: Karen Coyle <[email-masked]>
Date: Tue, 17 Feb 2009 12:33:55 -0800

Thanks, Will. I took a look at some of this, and have some questions 
about your system entities. You have both 'item' and 'component' defined as:

Item:
· a discoverable unit in the digital repository.
· An item contains 0 or more components.
· If an item contains 1 or more components, it must also contain a 
structural metadata record.
· An item must contain one or more descriptive metadata records.
· An item is typed; the item type determines what components are valid.
· An item may have relationships with other items; ie. [item A] 
isMemberOfCollection [item B]
· An item will be assigned a status: Incomplete, Complete, Published, etc.
An item can be qualified with arbitrary indicators ("Needs translation") 
that relate to the workflow of a
given project.

Component:
· an atomic unit of digital content. For example, an image, a page of a 
book, a text document, a pdf.
  A component contains a bitstream representing the content, or a URI 
pointing to a bitstream, as well as
administrative metadata for the bitstream.

This may need further explanation, as I am puzzled about the item being 
typed, but the component not. It seems to be that definition of 'item' 
and 'component' may be in the eye of the beholder, and that at either 
level you would need to be clear about the digital type. It also seems 
that many items will be of more than one type (text and images being a 
prime example, but there is the whole 'kit' concept in description 
cataloging.)

If you'd like discussion to be on the blog, I can paste the question 
into the comments area.

kc

Will Sexton wrote:
> I posted here early in the winter on Duke's plans to develop a 
> software tool to support metadata creation.  Our project has moved 
> forward with the hiring of two programmers and an intensive phase of 
> analysis and design.  We want to share our progress as we go, so I've 
> composed a post with some of our design documents at
>
> As always we welcome feedback from the code4lib community.  
> Regrettably, we'll not send anyone to the conference next week, but I 
> thought I would use this very nearly calm moment  to report on our 
> progress and invite discussion.
>
> Best,
>
> Will
> -- 
> Will Sexton

-- 
-----------------------------------
Karen Coyle / Digital Library Consultant
[email-masked] http://www.kcoyle.net
ph.: 510-540-7596   skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------

---

From: Will Sexton <[email-masked]>
Date: Tue, 17 Feb 2009 16:14:08 -0500

Karen, thanks for the feedback.  Is it ok if I opt for "eye of the 
beholder"? :)  We based our thinking for these models on the METS 
standard, where the component roughly corresponds to a file, and 
multiple configurations of files may exist for an item.  It does seem 
kind of strange that we might have an item, for example, something from 
our American Songsheets collection, which we call an "Image" type, but 
which has both JPEG's and TEI documents associated with it.  I wouldn't 
mind the English-usage misdemeanor as long as those files or components 
get successfully translated to services from the user's point of view:  
"View the image" | "Search the text".

We haven't been very specific about defining what our types are, and I 
don't know, but maybe the best response is, our typing won't be that 
strong.  Or at least, it should be extensible.  Anyway, I think you've 
identified one of those places where we'll be bargaining with the devil 
when we get to the details.

Will

Karen Coyle wrote:
> An item can be qualified with arbitrary indicators ("Needs 
> translation") that relate to the workflow of a
> given project.
>
> Component:
> · an atomic unit of digital content. For example, an image, a page of 
> a book, a text document, a pdf.
> This may need further explanation, as I am puzzled about the item 
> being typed, but the component not. It seems to be that definition of 
> 'item' and 'component' may be in the eye of the beholder, and that at 
> either level you would need to be clear about the digital type. It 
> also seems that many items will be of more than one type (text and 
> images being a prime example, but there is the whole 'kit' concept in 
> description cataloging.)
>

---

From: David Kennedy <[email-masked]>
Date: Tue, 17 Feb 2009 16:37:06 -0500

Karen,

Thank you for your interest and comments.

To follow a little more on Will's response:

We also see components as being typed.  I think we just left this out of 
the system entities description.

We are using item type to aggregate tasks in the repository, determine the 
item's content model in the repository, what services should be exposed 
for the item, when the item is considered 'valid', etc.

Mixing media types within an item is doable.  And it may be best to add 
new item types as needed or extend existing item types to accomodate. 

I like your suggestion that an item could have more than one item type. 
This seems very elegant and object-oriented.  But it might also present 
some challenges in terms of aggregating tasks and determining when an item 
is valid and publishable.  I'll have to think this through some more.

As Will points out, we do have the same use case, with TEI and JPEGs.  And 
I don't know that we will know what solution works best for us until we 
get to the details.

Dave

-----
David Kennedy
Systems Programmer
Perkins Library, Duke University
(919) 613-6831
[email-masked]

Will Sexton <[email-masked]> 
Sent by: Code for Libraries <[email-masked]>
02/17/2009 04:16 PM
Please respond to
Code for Libraries <[email-masked]>

To
[email-masked]
cc

Subject
Re: [CODE4LIB] Duke metadata tool project

Will