Re: metadata namespace screw cases and DC/RDF

From: Karl Ove Hufthammer (
Date: Tue May 14 2002 - 14:27:26 EDT

  • Next message: Karl Ove Hufthammer: "Re: design question -- localized metadata?"

    Paul Rohr <> wrote in

    > I've just finished skimming the DC stuff too, and I agree that
    > we'll need a superset approach.

    I agree.

    > As for switching to RDF, the big question for me is whether
    > adding all that code is really need to help us solve this
    > namespace problem. If not, I'm tempted to follow the simpler
    > precedent already in place for HTML:

    IMHO, that's a satisfactory solution.

    > In short, the idea would be that we preface any of *our* keys
    > which are DC-compatible with the DC prefix.

    Note that this *also* solves key name clashes in different
    languages. E.g. if the word 'title' means something in language
    'xxx', and the UI is 'xxx', the user may try to use the reserved
    name 'title' for his metadata.

    > All others --
    > whether defined by Word or by users -- go at top level.

    I would rather see them prefixed by 'custom.' or something
    similar. We *may* chose to support other metadata standards in the
    future[1], and IMHO it's better if *all* keys are prefixed.

    > a few other notes
    > -----------------
    > 1. For those of you who read the above date examples
    > carefully, I'm not sure whether our canonical datetime output
    > should include the timezone offsets or not. For details, see:

    I would prefer if they did.

    > 3. FWIW, I'm not sure it's all that safe to map Word's
    > company onto DC's publisher. Word actually has a separate
    > publisher keyword in their custom tag.

    Then we shouldn't map it, IMO.

    > 4. Getting back to my original metadata vs. document
    > properties thread, is a DC.language property the right place
    > to store the document's default language,



    [1] E.g. A-Core <URL: >.

    Karl Ove Hufthammer

    This archive was generated by hypermail 2.1.4 : Tue May 14 2002 - 14:31:47 EDT