 |
 |
Roland said: > > Think Rachel's already made a remark on the issue. This > > restriction is not really what we want. Andy said: > I tend to disagree - but I guess that we probably could go > either way on this. Yes. It seems to me that whether defining Qualified DC "tightly" or "loosely" is "good" or "bad" depends on what we are defining it for. In the context of http://dublincore.org/documents/dc-xml-guidelines/ at least, I saw defining "Simple DC" and "Qualified DC" as providing specific permutations of DC metadata terms (I'm trying to avoid saying "profile") as the basis of "exchange formats", if you like i.e. if a data provider said they offered SDC/QDC, a service provider would know exactly what to expect. I think there is evidence that "Simple DC" is useful for this purpose in the "real world" (e.g. it forms the basis of the "oai_dc" metadata format used in OAI-PMH). I interpreted Rachel's comment as suggesting that there was rather less evidence that (tightly defined) QDC served a similar purpose, not because the model of refinements and encoding schemes is flawed, but because that precise permutation doesn't meet any specific real world application needs. I think she's probably right on this. Having said that, I'm not sure it follows from that that a completely "loose" definition of QDC is the solution, for the reason Andy suggests in his next paragraph. It just makes the concept of QDC rather meaningless, it seems to me. > If a Qualified DC metadata record can include external > properties then the logical conclusion is that a metadata > record that contains 50 IEEE LOM properties and 1 DC property > is a Qualified DC metadata record. That feels non-sensical > (or, at least, non-intuitive) to me. Yes, I agree strongly with this. > A metadata record made up of 50 LOM properties and 1 DC > property is a LOM record that 'incorporates' qualified DC (IMHO). > > > We first should say, what model DCMI has w.r.t. metadata in general. > > Yes, I agree that this is a possible approach. We *could* define a > > DCMI Abstract Metadata Model > > which would be broader than the model I propose. > > The main benefit in doing so would be if others, e.g. IEEE > LOM, were to adopt the same model. > > That said, I think there's enough in the current document to > allow people like IEEE LOM to adopt the same model if they > desire and write it up as an IEEE LOM abstract model. > > > Then we can continue in indicating what a simple DC or qualified DC > > interpretation of a given record should/could mean. > > > > Seems un-practical to me to insist on using DC vocabulary > > exclusively in a record - > > Where is this insisted? The document certainly doesn't > insist on this. The only restriction is on what a metadata > record labelled 'qualified DC' looks like. The document > explicitly acknowledges that most real-world applications are > not 'pure' qualified DC. [snip] > I think encoding schemes are different to properties. It > seems fine to me that a qualified DC record can contain > encoding schemes from external namespaces. It's only a gut > feeling though I guess. Yes, that was where I was heading too, I think, particularly after Tom Habing had introduced the distinction between value dumb-down and element dumb-down. Pete