DCMI Architecture Forum telecon - 2007-12-05
Present: Mikael Nilsson, Pete Johnston, Tom Baker, Peter Murray
Replay: http://flashmeeting.open.ac.uk/fm/4c7912-10691
Tom reports on finalizing DCTERMS
The following will be be published on 14 January
-
"Revisions to DCMI Metadata Terms" - an update of: http://stage.dublincore.org/usage/public-comment/2007/07/dcterms-changes/
-
Domain and Range specification - an update of: http://stage.dublincore.org/documents/2007/07/02/domain-range/
-
Updated DCMI Metadata Terms documentation (Web page) including "Domains and Ranges" and "Revisions to DCMI Metadata Terms" http://dublincore.org/documents/dcmi-terms/
-
Updated RDF schemas - including new schema for dcam: namespace.
-
DC-RDF as a DCMI Recommendation (now that dcterms: terms are published)
-
Remove sentence from DC-TEXT description about dcterms: terms.
-
Note that DCTERMS document will include an introduction describing set of changes. Explanatory material may be needed in other contexts as well.
-
Tom will post excerpts from the RDF schemas on DC-ARCHITECTURE in order to discuss the schema patterns.
Status of DC-HTML comment period (now ended)
-
Pete: comments we had:
-
Ivan comments, broadly positive with editorial suggestions, make captions clearer, etc.
-
Ann comments for minor clarifications and backwards compatibility issue (have responded on list)
-
Irvin Flack: broadly positive but highlighting issue of nature of support for non-literal value surrogates - lack of VES URI. Solving this problem would require an overhaul of approach.
-
Publish DC-HTML as a DCMI Recommendation as well?
-
Mikael: major issue is backwards compatibility. Have until January to do this. We are in position to finalize this document.
-
Tom: backwards compatibility note is key. Put the expressivity of HTML syntax into a context so that people can see whether meets needs. One comment on spec, presentational: put feature of DCAM and supported features side-by-side in columns -- easier to read.
== ISO 8601 ==
-
Mikael proposed an SES covering all of ISO8601. Educational community uses the whole standard.
-
Tom: There was a discussion several years ago.
-
Pete: ...discussion whether entire ISO 8601 corresponded to one datatype.
DC-TEXT
-
Mikael: not really a proposal, no need for Public Comment period.
-
Pete: we did have a public comment period for my note on Element Refinement, http://dublincore.org/documents/dc-elem-refine/. Note is stable, though there may be some uncaught transcription errors in migrating from wiki.
-
Tom: If there are errors, can be corrected with Errata Note.
-
Mikael: Is citable now: http://dublincore.org/documents/dc-text/, http://dublincore.org/documents/2007/12/03/dc-text/
DC-XML
-
Mikael: Ann using in project - finds proposed DC-XML too verbose and complex.
-
Pete: DC-XML-Full proposal is different from having property URI correspond to element name. Question is: how is one interpreting the format? If we take DCAM description model as starting point, then making everything very explicit and readable. Ann Apps: difficulty persuading others to use Full format? To me, comes back to underlying issue of emphasizing DCAM description model. Ann's argument more about the human readability issue than about how extensively it supports DCAM.
-
Mikael: Requirements for full format are easy: "support DCAM". Requirements for minimal format are less clear. Need to ask the community before proceeding. We would need strong requirements to guide development - otherwise no basis for proceeding. So move forward with full format. Shouldn't be negative about possibility of Minimal format, but would need to understand requirements better. Will post this on mailing list.
-
ACTION 2007-12-05: Mikael to post to DC-ARCHITECTURE re: requirements for Minimal DC-XML
-
Pete: Need to align naming conventions (for names) between DC-XML and DC-HTML. Surprised to see W3C published new CURIE spec - just a Working Draft, but puts CURIEs back on the table as something to use for DC-XML syntax. Tom will follow up.
-
Mikael: Several groups (e.g., RDFa) don't really use CURIE as an independent spec but (in effect) include in their own specs. Not depending on CURIE syntax as a separate entity - creating chaining problems.
-
Mikael: CURIE's would make automatic processing harder, so inclined not to support it at all in the Full version. In Minimal version, one could picture a pre-processing step to bring Minimal to Full. CURIE helps with HTML, which is often hand-edited, where terseness is an issue, but I am no longer a proponent of having it in the Full version.
-
Pete: Will work on the basis of using what we got and drop CURIE issue for now.
Next meeting: not in December, but in week before 14 January:
-
Friday, 11 January possible, but earlier in week is better:
-
Tuesday, 8 January, 1400 UTC