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:
> 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
>>
>> 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
>>
>>
>
>