> DCRDFTaskforce/PublicCommentJune2006

Report from public comment period on Dublin Core RDF expression

Period: 30 May - 30 June 2006

The following is a report of the feedback received during the public comment period on the new Working Draft "Expressing Dublin Core using the Resource Description Framework". A summary of the discussions and proposals for moving forward are presented in the sections below.

The consequences of adding domains and ranges to DCMI properties

Some concern has been raised concerning the proposal to add ranges and domains to the definitions of the DCMI properties. While strictly not part of this public comment period, the possibility of adding domains and ranges has been explicitly recognized in the new Working Draft. If domains and ranges are added, it is also clear that the RDF expression of certain metadata constructs (such as for dc:creator) will be different as compared to earlier RDF expressions from the DCMI. In particular, several uses of literal strings as direct values of properties will be made invalid. Based on Swoogle statistics on the usage of DCMI properties, it is clear that a vast majority of uses of the 15 core elements in RDF are literal uses, and hence problematic.

Concern has also been raised that the notions of domains and ranges are not part of the DCAM.

Proposals

References

The relationship between encoding schemes and the corresponding RDF concepts.

This comment period about expressing DCAM-based metadata in RDF has revived an older discussion about the status of "vocabulary encoding schemes" (VES) in the DCAM itself. Both the Proposed Recommendation from 2002 on expressing qualified Dublin Core in RDF and the DCAM itself model a VES as "the type of a value". This approach has been followed in the current DC-RDF draft, which uses the "rdf:type" property to express VESs.

Traditionally, the function of VES has been to "indicate that the value is a term from a controlled vocabulary" (see the [WWW]principles document), and the comment period has made clear that this traditional definition does not fully overlap with the RDF notion of Class, which encompasses non-vocabulary-like entities such as Person and Date.

A proposal has been put forward to modify the DCAM in order to separate the notions of "vocabulary encoding scheme" and "value type", which in the current version of the DCAM are seen as equivalent.

Proposals

References

The use of rdf:value

It has been suggested that the proposed new RDF property "dcrdf:valueString" would be dropped. Instead the rdf:value property could be used. This would allow for partial compatibility with the existing Qualified Dublin Core RDF expression. Note that the proposed "dcrdf:valueString" RDF property was intended to be a sub-property of rdf:value, so much of the same semantics would be retained.

It has also been suggested that dcrdf:valueString overlaps too much with using a dc:title in a related description of the value. There is some merit to the argument, even though the value of dc:title is not necessarily a "value representation". Certainly it is the case that an application looking for text for indexing of the value would look at both rdf:value, dc:title and possibly other properties.

Proposals

References

The use of datatyped literals as objects of RDF statements

The use of literal strings as direct values of RDF properties is still not fully understood. Note that using value strings in general is relatively unproblematic, even when used in combination with Syntax encoding schemes (SES). This issue has to do with the case when the range of a property allows for literal values (such as possibly dc:title and maybe dc:date), especially when that value is combined with a syntax encoding scheme. It is currently somewhat unclear what the precise interactions between ranges, value types, VES, SES and literal values are.

As this issue is heavily influenced by the decision on the value type and VES issue mentioned above, a final solution needs to wait for that issue to be finalized.

Proposals

References

The use of dc:type vs. rdf:type

It was discussed whether using dc:type in RDF metadata was recommended, as the semantics overlap nearly or completely with rdf:type, especially after the introduction of a range of "Class" for dc:type. Using rdf:type would certainly increase interoperability with other RDF metadata.

Proposals

References

The use of rich representations

Several issues have been brought up regarding rich representations:

These issues are really DCAM issues. The DCAM s unclear on the exact nature of rich representations, and the current wording in the DC-RDF draft is a best-effort formulation.

Proposal

References

Using syntax encoding schemes and language tags simultaneously

Currently, the DCAM allows value strings to carry both a language tag and a syntax encoding scheme, while the draft DC-RDF expression does not allow this.

Proposals

References

Conclusion

The draft did not meet with substantial opposition. There are a few minor issues within the draft that we should address, and then a few larger issues that have to do with the interaction between DC-RDF, the DCAM and the definitions of the DCMI terms.