Title:             DCMI Abstract Model
Identifier:        http://dublincore.org/usage/meetings/2004/10/ISSUES/abstract-model/
See also:          http://dublincore.org/usage/meetings/2004/10/ISSUES/
Created:           2004-09-13
Agenda frozen:     2004-10-02 07:25, Saturday
Archived:          2004-11-10
Maintainer:        Tom Baker
Note:              If any of the links below are broken, please refer to 
                   the meeting packet
                   (http://dublincore.org/usage/meetings/2004/10/Meeting-packet.pdf) 
                   for copies of the key documents discussed at the meeting.

Shepherd: Andy

This topic has several related threads:

1. The draft DCMI Abstract Model [1]

   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
          points throughout

        - 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
          resource model

        - 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].

   [1] http://www.ukoln.ac.uk/metadata/dcmi/abstract-model/
   [2] http://www.ukoln.ac.uk/metadata/dcmi/dc-usage/am-issues/

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" [2], which has subsequently
   been discussed on DC-ARCHITECTURE [3].

   [2] http://www.ukoln.ac.uk/metadata/dcmi/term-identifier-guidelines/
   [3] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0409&L=dc-architecture&T=0&F=&S=&P=62

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
        the definitions.

5.  Modelling DC Values as Resources in RDF

    In September, Andy posted a discussion paper [4]
    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.

   [4] http://www.ukoln.ac.uk/metadata/dcmi/rdf-values/

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

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0405&L=dc-architecture&T=0&F=&S=&P=567

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0406&L=dc-architecture&T=0&F=&S=&P=57

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:

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0405&L=dc-architecture&T=0&F=&S=&P=567
http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0406&L=dc-architecture&T=0&F=&S=&P=57