Hi everyone!
We are a bit more than halfway through the public comment period, and a
few important issues have been discussed. All issues brought forward
will be noted and taken into account for the next steps. The main items
so far have been:
* The relationship between encoding schemes and corresponding RDF
concepts.
* The consequences of adding domains and ranges to DCMI properties
* The use of rdf:value
* The use of datatypes as objects of RDF statements
* The use of dc:type vs. rdf:type
* The use of rich representations
I would like to add some general remarks regarding the current Draft, in
order to clear up some potential confusion that might otherwise result.
1. Regarding value strings and the new ranges of certain properties.
If we (or rather, the Usage board) modify dc:creator (and others) to
have a range of Agent, that will imply that strings are no longer
allowed as direct values of the RDF property dc:creator. However, it is
still perfectly possible to use value strings attached to the Agent to
give the name, etc. of the creator, as described in the DCAM. So the
string representation of creators is not going away, it is just moved to
a slightly different substructure in the RDF graph (the same place as it
already is in the old DCQ-RDF proposed recommendation).
2. Regarding encoding schemes and RDF concepts
Regardless of how we choose to exactly interpret the notions of syntax
and vocabulary encoding schemes in RDF (and it does matter for RDF
applications!), the basic notions as defined by the DCMI will not go
away. We may need to clarify a bit what a "syntax" is and what we really
mean by "vocabulary", but I don't expect that to negatively impact any
existing encoding schemes.
3. Regarding dc:type
My suggestion for recommending against the use of dc:type in RDF
metadata does not imply that dc:type is somehow "deprecated", but rather
that the use of dc:type is redundant and can already be inferred from a
statement using rdf:type. So it's only a question of increasing
interoperability with other RDF metadata while still retaining DC
compatibility.
4. Regarding DC RDF generally
I would like to take this opportunity to point out that the new DC RDF
draft is firmly grounded in the DCMI Abstract Model, and aims to
increase compatibility between RDF applications and the DCAM. In the
process of producing the draft, we have carefully tried to bring the
expression in harmony with the DCAM, minimizing the amount of
idiosyncrasies.
This means that most of the questions that arise regarding the nature of
encoding schemes etc. are really questions about what the DCAM should
say on the matter. The DC RDF specification should ideally simply follow
those definitions. Now, the issue seems to be that some of the
definitions used by the DCMI are a bit less clear than they could be,
leading to some potential ambiguity when the concepts are transferred to
RDF.
The same goes for the definitions of domains and ranges - while maybe
mostly RDF applications will make advanced use of those definitions,
they are still fundamental to the definitions of the DCMI properties
themselves, independently of RDF.
Looking forward to more discussion!
/Mikael
|