Comments on the april 2007 version of DC-RDF
The following comments and issues were raised during public comment for the
april 2007 version of DC-RDF.
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
Proposals
-
No change required.
RDF summary
It was suggested that the RDF summary would go into an appendixProposal
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
Proposal
Should be done.Wording section 4
The language on describing value at the end of section 5 could be improvedProposal
Improve languageWording section 5
Suggest improving the "Value classes" bullet list with concrete examples.Proposal
Should be donedcterms:type issue
Examples use dcterms:type but text says to use rdf:type.
Proposal
Examples are correct; dcterms:type in DC-TEXT should be converted to rdf:type in RDF.Examples description improvement
Add plain language describing the content of the metadata examplesProposal
Should be doneExample of multiple languages
Add multiple language strings in multiple languages to one of the examples.Proposal
Should be donerdfs: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 assertion that dcterms:type is rdfs:subPropertyOf rdf:type.Proposal
This is a UB issue, really.-
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 nodesUpdates
Some further comments:
(i) Some of the DC-Text examples (in the main text and in the appendix) include a namespace declaration for
@prefix rdfs: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
I don't think the rdfs prefix is ever used in the examples, so it doesn't result in any problems, but I guess it might be confusing to the casual reader who is accustomed to seeing that URI associated with the rdf prefix. I think it could be removed without causing any problems.
(ii) In the fifth example in the appendix table, the RDF/XML has an XML Namespace declaration
xmlns:dcam="http://purl.org/dc/rdf/"
which I think should be
xmlns:dcam="http://purl.org/dc/dcam/"
and in this case the dcam prefix is used in a QName for a property URI, so it does matter.
(iii) In the sixth and eighth examples in the appendix table, the RDF/XML has an XML Namespace declaration
xmlns:dcrdf="http://purl.org/dc/rdf/"
which I think is a hangover from the previous version. I don't think the XML uses any QNames with the dcrdf prefix (because we switched from using a DCMI property to rdf:value), so again it doesn't cause any problems, but I think that declaration can be removed (and probably should be so that people don't start speculating that there is some other set of URIs waiting in the wings)
(iv) The targets of several of the hyperlinks in the references section are stage.dublincore.org URIs (so throw up an authentication challenge when clicked); they should just be dublincore.org URIs
As this is still a "Proposed Rec", I assume it is fine just to make
those edits when we are preparing the "Recommendation" version. i.e. I
don't think it's sufficiently urgent to merit re-editing/re-posting the
document immediately - but if you want to get it out of the way, go
ahead!