innovation in metadata design, implementation & best practices
Title: DCMI Abstract Model
See also: http://dublincore.org/usage/meetings/2004/10/ISSUES/
Agenda frozen: 2004-10-02 07:25, Saturday
Maintainer: Tom Baker
Note: If any of the links below are broken, please refer to
the meeting packet
for copies of the key documents discussed at the meeting.
This topic has several related threads:
1. The draft DCMI Abstract Model 
Andy's draft DCMI Abstract Model (AM) was discussed in Bath.
In Bath, the UB agreed that the AM may overlap with the
Grammatical Principles (GP) document as long as the two
documents are clearly cross-referenced and carefully
maintained in alignment. There was an action on Tom and
Andy to bring the GP up to date using AM as the "source"
at such time as AM is approved as a DCMI Recommendation.
As of September 2004, this has not yet happened, so the
action will be carried forward.
In Bath, there was a further action on Andy to forward
text to Diane and Stuart for inclusion in the updated
Process document. It is not clear whether this has been
done or is still necessary.
On 2004-09-30, Andy posted a new version:
I haven't kept a detailed log of the changes that the
other authors and I have made since the last public
version, but here's a list of the things that I can
remember us doing!
- changed 'URI' to 'URI reference' at appropriate
- added 'description set' to the 'description model'
and associated UML class diagram (see figure 2 and
section 3) to separate out the conceptual grouping
of related descriptions (a 'description set') from
its instantiation in a particular syntax (a 'record')
- introduction of 'property/value pair' into the
first two bullet points of the 'resource model',
the associated UML class diagram and the terminology
section - to separate abstract notion of a property
from the specific usage of a property to describe
a particular resource
- modified the definition of 'sub-property' in the
- added of a note about needing to indicate how
'resource URIs' and 'value URIs' are handled in
encoding syntax specifications (section 7)
- explicit indication that 'resource URIs' and 'value
URIs' are not supported by the current XML encoding
guidelines (appendix C)
- explicit inidication that 'resource URIs' are not
supported by the XHTML encoding syntax (appendix D)
I am hopeful that this version is ready (or very
close to ready) to being moved forward as a Proposed
Recommendation. Please let me know if you have strong
views that this should not happen.
Andy will say whether he feels there are any technical or
policy issues related to the Abstract Model that need discussion
by the Usage Board in Shanghai .
2. "Guidelines for assigning identifiers to metadata terms"
In Bath, there was an action on Andy to formulate guidelines
on how people can declare their own URIs -- for example
by using InfoURI -- as a basis of discussion.
On 2 September, Andy posted a draft "Guidelines for assigning
identifiers to metadata terms" , which has subsequently
been discussed on DC-ARCHITECTURE .
3. Clarifying regarding non-DCMI-maintained terms (URIs)
In Bath, there was an action on Pete and Roland to draft a a
clear explanation of why an XML element is not an RDF property
(statement of problem) and a proposal for Usage Board policy
concerning XML elements. This policy was supposed to help
determine whether we re-consider a proposal for a DC refinement
or make a decision about reusing the MODS element.
On the basis of the explanation from Pete and Roland, Rebecca
was to find out whether a simple human-readable statement
could be devised by the MODS maintainers to clarify the
appropriateness of such usage.
4. Definitions of DC-15 in light of the Abstract Model
A 'value entity' may have a 'value string' and a 'value URI'.
In September 2003, Andy noticed:
However, digging too deeply into this uncovers some
horrible holes in the definitions of the 15 elements.
For example, the value of dc:identifier is not
'the resource' (a physical or conceptual entity) but
'a reference to the resource' (a conceptual entity).
(I.e. in RDF, the value of dc:identifier should never
be a resource). The same is true of dc:relation
('A reference to a related resource') and dc:source.
This seems to run counter to other definitions in
DCMES - e.g. dc:creator, which is defined to be
'An entity...' (rather than 'A reference to an
entitiy...'). This is probably a little unfortunate.
Similarly, the definition of dc:rights is at odds
with the other definitions because it effectively
defines the value to be either a 'rights statement'
or a 'link to a rights statement'. None of the other
definitions allow for the explicit possibility of
linking to the value.
In the abstract model, it would be nice to skirt
over some of these issues and assume that the value
of dc:rights is a 'rights statement' (a conceptual
entitiy) and the values of dc:relation, dc:source
and dc:identifier are 'resources' (physical or
conceptual entities). Both cases, the 'references to
the resources' and the 'link to a rights statement',
should be handled by the model (using 'value URI' and
'related metadata' respectively), not hard-coded into
5. Modelling DC Values as Resources in RDF
In September, Andy posted a discussion paper 
shining a bright light on the long-recognized but
hitherto-glossed-over differences in how DCMI's
specifications for encoding DC metadata in RDF treat
values -- whether as resources or as strings -- and how
DCMI might proceed to address this important issue.
6. Vocabulary Encoding Schemes and Syntax Encoding Schemes
I'd like to see this issue expanded slightly to cover the question I
asked back here
about whether the terms within the DCMI Type Vocabulary are also
encoding schemes. I think clarifying this point may be helpful in
explaining some of the syntax issues.
Pete has raised the question on dc-architecture of whether
the DCMI Type Vocabulary Terms are also encoding schemes: