[Dspace-general] list of resource Types in DC metadata
Mark Diggory
mdiggory at MIT.EDU
Fri Jun 13 19:50:09 EDT 2008
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
More information about the Dspace-general
mailing list