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
|