[Dspace-general] list of resource Types in DC metadata

[Mark Diggory]

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 DSpace at MIT, 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