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

[Mark Diggory]

I would add, that my hopes are focused more on the fledgling  
bibliontology project to provide an initial  set of "Types". Which  
may fit nicely into the dc:type concept.

http://bibliontology.com

Cheers,
Mark

On Jun 13, 2008, at 4:50 PM, Mark Diggory wrote:

> 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
>
>
>
>
>
> _______________________________________________
> Dspace-general mailing list
> Dspace-general at mit.edu
> http://mailman.mit.edu/mailman/listinfo/dspace-general



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