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 [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 > > > > > > _______________________________________________ > Dspace-general mailing list > [EMAIL PROTECTED] > 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 ------------------------------------------------------------------------- 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
