Application Profile of Simple Dublin Core (Tom, Mikael)
Notes from the discussion in Singapore, August 2007.
http://knowware.nada.kth.se/DCWiki/SimpleDublinCore?action=print
Question being addressed is "What do we want to say simple DC is?". This work needs to be based on what functions we are trying to provide for.
-
1. To provide an AP that tells implementors how to use the traditional '15' in a way that conforms to modern understanding of metadata descriptions based on the DCAM.
-
2. Scope and purpose based on the mature understanding of the UB, developed over the last 6 years.
To be explicit about a number of things, to comment, to point out flaws and do some house cleaning.
Something that looks very much like the DC15; go into spatial and temporal; provide a pedagological clarification of the 'core'.
The new AP is not intended to solve the general problem of 'resource description', which is best addressed by communities in Application Profiles.
How to deal with source and identifier without going beyond the 15? NB We are not starting from scratch.
Purpose (MN): to serve as a path for implementors of the simple DC to move towards a more modern implementation of DC metadata terms.
Need to have a relatively conservative interpretation of the OAI-PMH version of DC.
Need for a second profile - but what is its function and scope?
Describe the legacy and the path to the new - in two profiles but presented as one package.
Straightforward to create a AP for traditional 'simple DC'. Then...?
A second AP that provides a modern way of implementing what people think of as 'simple DC' (but called something else).
To reverse engineer traditional use of 'simple' DC.
Reconstruct a new version of what was called 'simple DC' that implements modern understandings and ameliorates existing flaws in the DC15.
APs or description set profiles?
ACTION 2007-08-26: Tom and Mikael to create a draft AP using the 1.1 namespace and which models everything as literals. Document the legacy functional requirements and the organizational context for this AP.
AGREED: Defer, for the time being, work on a second AP until we have a better understanding of the functional requirements, scope and purpose of this second AP.