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
[log in to unmask]
Will Sexton <[log in to unmask]>
Sent by: Code for Libraries <[log in to unmask]>
02/17/2009 04:16 PM
Please respond to
Code for Libraries <[log in to unmask]>
To
[log in to unmask]
cc
Subject
Re: [CODE4LIB] Duke metadata tool project
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
>>
>>
>
>
|