 |
 |
On Feb 26, 2007, at 4:43 AM, Mikael Nilsson wrote: >> Frankly, I do not see any other solution. The current approach, in my >> view, penalizes a large user community... > > The DCMI community has struggled with this exact issue for a few years > now. The hope is that this compromise leads to the best of both worlds. > Of course, feedback on that is more than welcome! But WRT to Ivan's suggestions here (either to not limit these particular properties, or to use the OWL unionOf option to offer a choice), where is the compromise? As you say above: > In the long term, that will hopefully mean than more and more uses of > Dublin Core will make use of the semantically richer terms in the > dcterms: namespace (as well as unifying all terms in a single > namespace). This makes a whole lot of sense for most of the properties, but I actually think it would be a bad thing to see everyone modeling titles and dates and descriptions as full resources. E.g. you seem to characterize this (richer description) as best practice, but I don't think it is in all cases. Moreover, the wide practice of modeling titles and dates as resources will never happen practically because most people (developers and non-developers alike) would consider it overkill, which then leads to an even bigger problem that I thought this effort was designed to overcome (inconsistency). Just as a practical matter, I'm working with the OpenDocument group at OASIS on adding RDF support to the format, and on related work on citations. I was excited to see this effort to clarify DC because we can just point developers to your documentation and be content that they will know what to do. But I would find it really awkward to tell developers "well, OK, use dcterms namespace for most properties, but if you want to treat titles as literals, better to use dc:title." Bruce