 |
 |
Mikael said: [snip] > My gut feeling is that these are a bit too much at the moment. I'd > prioritize updating the current DC-in-HTML spec to be DCAM-compatible. > It seems to me that this also makes most existing DC-in-HTML metadata > more or less compatible? I think so. The main issue where there is an "incompatibility", I think, is the use of the meta/@scheme attribute. The new draft specifies that meta elements map to statements with literal value surrogates, and that values of @scheme map to SES URIs, whereas in the past @scheme has been used for both VES and SES URIs. So I think "naively" applying the "new" interpretation to documents encoded using the "old" spec will result in some statements with strangely typed literals as literal value surrogates. > Later on, we can simply describe how to use RDFa together with DC-RDF, > and slowly deprecate DC-in-HTML completely. Sounds good to me. > The above assumes that the issue of knowing when to trigger DC-in-HTML > parsing and when to trigger RDFa is solved. Yes. > But it seems to me that this is not a big issue, right? I think it's a "moderately sized" issue ;-) But I think it's an issue that RDFa has to address in the general case if it is to avoid the generation of lots of unwanted triples e.g. I think the problem I highlighted for the DCMI profile applies equally to all uses of Ian D's Embedded RDF profile too. Also specs like OpenId make use of a "prefixed name" convention in link/@rel attribute values without explicitlt associating that convention with a mapping to property URIs. So it seems to me all this "legacy data" is something RDFa has to handle, one way or another, and it is in the first instance an issue for the RDFa group rather than for DCMI. (Though having said that, if we can make any minor adjustments to smooth their path, then I'd like us to take such suggestions under consideration.) > So, to summarize, I propose to > > 1. Keep DC-in-HTML, but update to be DCAM-compatible > 2. Create DC-using-RDFa at a later stage, and make it > preferred over (1) over time. I'm happy with that approach. > > We may still want to consider changing the separator in > what I called > > "DC-HTML Prefixed Names" from a period to a colon? I'm not > sure whether > > that would be a good thing to do or not: given that they > aren't QNames > > and the prefixes won't be mapped to XML Namespace Names, it may be > > confusing to make that change. > > Plus it would leave existing data in the dark. Yes, agreed. Though note that the draft also proposes a new profile URI, so I guess strictly speaking data with the current profile URI remains in the dark, in the sense that the existng profile specifies no DCAM interpretation. > If we are to keep > DC-in-HTML as a non-RDFa solution, I think it's better to > keep it close to the old specs. Yes, that was very much the approach I had taken in creating the current draft. I'm quite happy to keep the period-separated prefixed names (and indeed would prefer to do so, not only for the backward compatibility reasons, but also on the grounds that I fear that adopting names which look rather like XML QNames but which aren't processed as XML QNames will inevitably lead to some confusion). Pete --- Pete Johnston Technical Researcher, Eduserv Foundation Web: http://www.eduserv.org.uk/foundation/people/petejohnston/ Weblog: http://efoundations.typepad.com/efoundations/ Email: [log in to unmask] Tel: +44 (0)1225 474323