Kate, (I'm cross-posting to dspace-tech because I think its an important forum for this as well)
An excellent question. I'll bite (with a bit of a vengeance). And I explicitly add that "This may not represent the Official Views or Opinions of MIT Libraries or the original authors of the DCMI Library Profile." On Jun 13, 2008, at 9:35 AM, Ekaterina Pechekhonova wrote: > > We want to use the default list of Dublin Core resource types which > comes with Dspace for another project. Do we understand it right, > that the list was developed in MIT Libraries (in accordance with > Dublin Core Libraries Working Group Application Profile) ? I've heard this said in the past by others and expect to hear from them about it. But, I think overall, its a misinterpretation by the DSpace community that the Library Profile somehow sets any more guidelines on these values than the DCMI dc.type does, which is "almost none". Maybe it was talked about in the past, but the Profile and all its past revisions don't go anywhere near formally defining a list of types and/or how to derive such types. What I read only suggests a few sources that might be good for basing types on like MARC Genres and DCMITypes, of which this list seems to take bits and pieces of.. http://dublincore.org/documents/2002/09/24/library-application- profile#Type The Library Profile states that dc/dcterms:type could "possibly" be populated with something like: http://dublincore.org/usage/terms/dc/current-schemes/ and/or http://www.loc.gov/marc/sourcecode/genre/genresource.html There is a considerable "Open Question" of: > Consider registering values defined in the MARC list of sources as > encoding schemes as well as any others that are identified as useful. Add to this... The suggestive Best Practice "statement" of including at least one DCMITType as a dc.type. Which I interpret to mean, "it'd sure be nice if your application somehow defined the values used in dc.types as SubClasses of true DCMI VocabularyEncodings". Drilling into the DCMI intentions for this term is an entertaining adventure... I've started to rely on the RDF schemas as the closest thing I can get to an intention for the field. dcterms.type only "suggests" the following "Vocabulary Encodings": http://dublincore.org/2008/01/14/dctype.rdf Collection Dataset Event Image InteractiveResource Service Software Sound Text PhysicalObject StillImage MovingImage All are subclasses of the DCMIType RDFS Class and are what are referred to as a "Vocabulary Encoding Scheme" in the DCMI Abstract Model. Anyone can extend DCMIType and introduce their own Vocabulary Schemes. This all suggests that any list of types suggested for dc:type (regardless of any Application Profile) is very subjective, localized to implementation (i.e. DSpace) and highly subject to interpretation. More personally, I feel that in DSpace's type list, the types often are only vaguely informative as to the true nature of the content we are dealing with. Animation Article Book Book chapter Dataset Learning Object Image Image, 3-D Map Musical Score Plan or blueprint Preprint Presentation Recording, acoustical Recording, musical Recording, oral Software Technical Report Thesis Video Working Paper Other I find it odd that some of the types are quite granular and specific (type of recording as Oral, Musical, Acoustical?!), while others are extremely generalized and abstract (Learning Object? Dataset? Article?). I'm unsure what an "Other" is, but assume its no better than just leaving the dc.type out altogether on my Items. Besides this, we are learning that the submitter, with a lack of knowledge about these types are, and/or not having an appropriate type for their item, will tend to misclassify it. For instance, how does one classify a researchers archived website Home-page, or any other website that doesn't meet the requirements of this list? For example here is a wonderful item in [EMAIL PROTECTED], its a dc:type=Image and an dc:type=Article http://dspace.mit.edu/handle/1721.1/5558?mode=full Heres another... classified as dc:type=Other http://dspace.mit.edu/handle/1721.1/7307?mode=full So, To be more specific, I'm rather wary of calling this a formal list, specifically because in DSpace there is no control over the field outside of the submission UI (for instance in Package ingest and ItemImporter. And its wholly acceptable to see other types entered here, note dc:type has no formal restriction on its value. Attempting to enforce a profile on it may benefit your local application, but will "always only be centric to that application". This is a great question! It opens my eyes to the misconception I had made based on the documentation and discussions with others about the Library Profile. I'm now will be more critical when the topic arises. As well, It reaffirms my opinions that I am on the right track in pushing that the DSpace metadata architecture needs some serious improvement if its going to be brought current with the evolving DCMI approaches. Part of this should be the consideration more formally defining this list while allowing for additions/refinements/ equivalencies to be added as needed! Cheers, Mark ~~~~~~~~~~~~~ Mark R. Diggory - DSpace Developer and Systems Manager MIT Libraries, Systems and Technology Services Massachusetts Institute of Technology Home Page: http://purl.org/net/mdiggory/homepage ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
