Mikael, et al,
1. I think it was me who suggested expanding the summary of the RDF model section, however I'm now thinking it's not really part of the specfication so maybe should move to an appendix? I'd quite like to keep section 2 but just with a sentence "A summary is presented in Appendix B" so people reading from front to back can discover and read the overview at the beginning of their reading.
2. In section 4 under the "Value strings, Value..." subheading it says "A DCAM syntax encoding scheme URI is represented using the RDF datatype URI associated with a RDF typed literal..." I'm wondering what to do with local datatypes that don't currently have a URI. According to the RDF Concepts document [1] (section 3.3), RDF doesn't provide a mechanism for defining new datatypes and you have to use XML datatypes, but not all XML datatypes are OK (section 5).
3. When I got to the diagrams in section 4 I really wanted to see the DC-Text for these so I could make mental associations between the DC-Text structure and how it works visually. Is it practical to include DC-Text for these?
4. The last part of section 4 (Describing values) - sorry, I don't understand what is being said here. Does it mean and value is fair game to be described elsewhere?
5. In section 5 under "Value Classes" - I felt adding some examples would help explain what the three list items mean. They seem to be bare assertions.
6. DescriptionSet appears to be mapped to rdf:RDF. rdf:RDF is usually the root node in an XML file - I'd like to know how I should encode multiple records/descriptionSets in a single XML file.
7. The 6th and 8th examples use dc:type however the specification recommends not to use them - to use rdf:type instead. People will likely be re-using these examples, so probably best they follow our own recommendations.
8. In the examples appendix, I'd like to suggest a description is added explaining what the person is trying to represent. This would make looking through them for examples to copy easier. This could be as well as, or instead of, the structural description. For example (in the order in the document):
1 - Subject term identified by a URI
2 - Subject term as a string from a specified vocabulary
3 - Title string in a specified language
4 - Age as a string of a specified type/syntax
5 - Subject term identified by a URI plus as a string in a specified language and as a string of a specified type/syntax
6 - Creator identified by a URI where the URI has a string, a DC Type, and a phone number specified as a URI
7 - Subject term identified by a URI, but for an unidentified described resource
8 - Creator as a string, a DC Type, and a phone number specified as a URI
9. It might be nice to include an example of multiple languages - eg. by extending the third example. Though this may depend on the outcome of the separate language issue already circulated on the listserv.
Here's a possible example:
<dcterms:subject>
<rdf:Description>
<rdf:value xml:lang="en">Canoe</rdf:value>
<rdf:value xml:lang="mi">Waka</rdf:value>
</rdf:Description>
</dcterms:subject>
NB: It's interesting to note that Waka is also the term used for Car, so this would need a separate Subject element:
<dcterms:subject>
<rdf:Description>
<rdf:value xml:lang="en">Car</rdf:value>
<rdf:value xml:lang="mi">Waka</rdf:value>
</rdf:Description>
</dcterms:subject>
10. Typo in section 4 under "Value URIs" subheading, second sentence, second word should be "no" not "not".
11. I noted in my DCAM feedback that I liked the rdfs:label structure as it was easy to work out which of the many representations was a good default to show a user/reader.
12. I lament that we now need to use full URIs for vocabulary encoding schemes as they are now in attributes (when they were classes we used shorthand like dcterms:W3CDTF). I know it doesn't really affect anyone, just a lament for those of us hardcoding things or trying to explain how it works to other people...
13. An aside, since all DC terms will become available under one namespace, I'm thinking of changing the prefixes I will use, ie. dcterms: prefix to dc: and the current dc: prefix to something else (maybe dcs: or dce:?). So I'll be using dc:title, dc:alternative,...
14. I have to admit I haven't gotten my head around the domains and ranges thing yet so don't have any comments on that yet.
Thanx,
Douglas
[1] http://www.w3.org/TR/rdf-concepts/
|