1 / 17

Miscellaneous Usage Issues

Miscellaneous Usage Issues. DCMI Usage Board, DC-2009, Seoul, Korea. Simple DC. Simple DC. Described informally in various DCMI documents From viewpoint of DCAM/Singapore Framework Either A “pattern” for constructing description sets i.e. a Description Set Profile Or

anoush
Télécharger la présentation

Miscellaneous Usage Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Miscellaneous Usage Issues DCMI Usage Board, DC-2009, Seoul, Korea

  2. Simple DC DCMI Usage Board, DC-2009, Seoul, Korea

  3. Simple DC • Described informally in various DCMI documents • From viewpoint of DCAM/Singapore Framework • Either • A “pattern” for constructing description sets • i.e. a Description Set Profile • Or • A DC Application Profile, which includes a DSP DCMI Usage Board, DC-2009, Seoul, Korea

  4. Simple DC as DSP: Suggestion 1 • DSP expression of “traditional” “Simple DC” pattern • Description set contains one description, of resource of any type • For each statement in description • Property URI must be from list of 15 properties of DCMES (i.e http://purl.org/dc/elements/1.1/title etc) • Literal value surrogate required • SES URI not permitted • Language tag optional DCMI Usage Board, DC-2009, Seoul, Korea

  5. Simple DC as DSP: Suggestion 2 • Singapore 2007 Proposal (Mikael/Tom) • DSP expression of a “modernised” “Simple DC” pattern • Description set contains one description, of resource of any type • For each statement in description • Property URI must be from list of 15 “new” properties of DC Terms (i.e http://purl.org/dc/terms/title etc) • Type of surrogate on case by case basis, depending on range • For literal value surrogates • SES URI not permitted • Language tag optional • For non-literal value surrogates • Value URI not permitted • VES URI not permitted • One value string permitted • SES URI not permitted • Language tag optional DCMI Usage Board, DC-2009, Seoul, Korea

  6. Issues • Are we labelling a DCAP or a DSP? • Both “patterns” are “valid” DSPs • What do we want to achieve? • To formalise the “traditional” pattern? • To develop a “modernised” pattern (based on new terms, ranges etc)? • Both? • Which do we want to label “Simple DC”? • And if we do both, what do we label the other pattern? DCMI Usage Board, DC-2009, Seoul, Korea

  7. Issues • “Dumb-down”? • Generation of “Simple DC” description set? • If “Simple DC” = “traditional” pattern • Does “dumb-down” imply mapping non-literal to literal? • If “Simple DC” = “modern” pattern • Non-literal supported in target so no need for mapping DCMI Usage Board, DC-2009, Seoul, Korea

  8. Dumb-down to “traditional” Simple DC “5 mins” dcterms:extent Doc:D dc:format Doc:D “5 mins” DCMI Usage Board, DC-2009, Seoul, Korea

  9. Dumb-down to “modern” Simple DC “5 mins” dcterms:extent Doc:D “5 mins” dc:format Doc:D DCMI Usage Board, DC-2009, Seoul, Korea

  10. Discussion • “Simple DC” as “traditional” pattern • Dovetails with existing informal documentation • “Intuitive” fit with e.g. oai_dc XML format • Ignores modernisation of terms • Continues to promote “blanket” usage of literal values • “Dumb-down” complexity? • “Simple DC” as “modernised” pattern • Recognises modernisation of terms • Promotes appropriate usage of literal/non-literal values • “Dumb-down” simpler? • Differs from existing informal documentation • Less “intuitive” fit with e.g. oai_dc XML format DCMI Usage Board, DC-2009, Seoul, Korea

  11. Use of dcterms:identifier DCMI Usage Board, DC-2009, Seoul, Korea

  12. Use of dcterms:identifier • Use literal values • e.g. URI as literal value, not “value URI” DCMI Usage Board, DC-2009, Seoul, Korea

  13. Use of dcterms:identifier • Within a single description, use dcterms:identifier only for identifiers of the described resource • Take care with resource/representation & resource/description (httpRange-14) issues DCMI Usage Board, DC-2009, Seoul, Korea

  14. Use of dcterms:identifier • Differentiating “identifier syntaxes” • Where represented as URI • use SES = dcterms:URI (or xsd:anyURI) • Don’t use SES = example:URN, example:UUID (etc) as these are all URIs • Where represented as non-URI literal • use SES? • SES = example:ASIN (etc) • (but e.g. BIBO uses subproperties) DCMI Usage Board, DC-2009, Seoul, Korea

  15. Use of dcterms:identifier • Differentiating “categories/purposes of identifier” • Subproperties for e.g. • “local identifier”? DCMI Usage Board, DC-2009, Seoul, Korea

  16. Miscellaneous Usage Issues Title slide photo “Seoul Gyeongbok Palace” by Flickr user storyvillegirlSee http://www.flickr.com/photos/bibbit/2948779230/Made available under CC Attribution-Share-Alike 2.0 license DCMI Usage Board, DC-2009, Seoul, Korea

  17. Dublin Core Description Set Profiles DC-2009, Seoul, Korea

More Related