Title:        Report from public comment period on Expressing Dublin Core 
              metadata using the Resource Description Framework (RDF)
Creator:      Mikael Nilsson
Identifier:   http://dublincore.org/documents/2007/04/02/dc-rdf/comments-received.html
Date:         

The following comments and issues were raised during Public
Comment for the April 2007 version of "Expressing Dublin Core
metadata using the Resource Description Framework (RDF)" [1].
The summary below refers to comments by Douglas Campbell [2] 
and Ivan Herman [3].

[1] http://dublincore.org/documents/2007/04/02/dc-rdf/
[2] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0705&L=dc-architecture&P=170
[3] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0704&L=dc-architecture&P=1308

Use of dcterms: namespace

     As of June 2007, a proposal [1] to replicate the fifteen
     properties of the http://purl.org/dc/elements/1.1/ ("http://www.standbyclick.com/spacer.gif")
     namespace in the http://purl.org/dc/terms/ ("http://www.standbyclick.com/spacer.gif")
     namespace has not yet been approved or implemented.

     Proposal: To leave references to dcterms:subject and
     dcterms:title as is for now pending approval of the
     replication proposal.  Status of DC-RDF will remain
     that of DCMI Proposed Recommendation.

     [1] http://dublincore.org/documents/2007/02/05/domain-range/

Value-VES relationship as instance-Of v memberOf

    Could the relationship between value and VES be expressed
    as instanceOf (rdf:type) (with VES as Class) rather than
    dcam:memberOf?

    The current recommendation takes this approach but that
    has been changed:

     * to avoid confusion with "traditional" DCMI concept of VES

     * the instance-of relationship between value and VES
       created problems for integration with SKOS, where the
       relationship between a concept and a concept scheme is
       skos:inScheme, not instance-of

    Proposal: No change required.

RDF summary

    It was suggested that the RDF summary would go into an appendix

    Proposal: As the RDF terminology and graph notation is used later
    in the document, the section should probably be kept.

Include DC-TEXT in all examples

    It was suggested that DC-TEXT should be used in all examples

    Proposal: Should be done.

Wording of Section 5

    It was suggested that the language on describing "value"
    at the end of section 5 could be improved

    Proposal: Improve language.

Wording section 5

    It was suggested that the "Value classes" bullet list be 
    improved with concrete examples.

    Proposal: Should be done.

Use of dcterms:type

    It was pointed out that examples use dcterms:type but text says 
    to use rdf:type.

    Proposal: Examples are correct. References to dcterms:type in 
    DC-TEXT converted to rdf:type in RDF.

Examples description improvement

    It was suggested that plain language describing the content of 
    the metadata examples be added.

    Proposal: Should be done.

Example of multiple languages

    Add multiple language strings in multiple languages to one of the examples.

    Proposal: Should be done.

rdfs:label preferred over rdf:value

    There is an issue with finding the right label for display purposes.

    Proposal: rdfs:label is not an option, as the semantics
    does not match the definition of value string.

dcterms:type vs rdf:type

    There is an issue with declaring a sub-property
    of rdf:type. OWL-DL will not accept the assertion that
    dcterms:type is rdfs:subPropertyOf rdf:type.

    Proposal: This is really an issue for the DCMI Usage Board.
    -- Remove statement that dcterms:type is rdfs:subPropertyOf rdf:type.
    -- State that in mapping from DCAM to RDF, dcterms:type maps to rdf:type.

Usage of rdf:ID vs rdf:nodeId

    Last example not clear about the mapping of DC-TEXT IDs

    Proposal: Make clear that no URI is created in the mapping of blank 
    nodes.