[sc34wg3] Comments on N884 (Dublin Core in TMs)

Murray Altheim murray06 at altheim.com
Sun Jul 15 17:26:53 EDT 2007


As it states in [DCER] (though notably this is not a DCMI
recommendation) regarding 'rdfs:subPropertyOf':

    The meaning of the refinement/subproperty relationship is
    defined by the RDF Vocabulary Description Language (RDF
    Schema): the existence of a subproperty assertion states
    that all resources related by one property are also
    related by the second property.

I think it would be a mistake to use a different predicate than
'refinement' as described in the DCMI documentation. Subtype or
subclass (as used in the Topic Maps specifications) do not mean
the same thing (though very similar in the vernacular), particu-
larly in this context since we do have both relations defined
there can be no ambiguity about them being different. It's
unfortunate that DC does not include a URI specifically for
'refinement' (or previously, 'qualifies', though at least they
did bother to eventually define it) but using different language
to describe a refinement relationship seems to be mixing models.

Murray

[DCER] Element Refinement in Dublin Core Metadata
        http://dublincore.org/documents/dc-elem-refine/
----
Lars Marius Garshol wrote:
> I think this is already pretty close to what we want, and what remains 
> is mostly tweaking. Below are some initial comments based on the first 
> reading. The purpose is mainly to raise points for discussion in 
> Montr�al, but if we can settle some of them before that, that would of 
> course be good.
> 
> ---Datatypes
> 
> Should we give concrete datatype URIs for the DC terms which have 
> datatypes, such as dc:type? I notice that DC does not actually commit 
> itself this far, but perhaps we should?
> 
> ---Subtyping
> 
> In Dublin Core some of the terms are "refinements" of other terms. For 
> example, dc:abstract subtypes dc:description. Doesn't that mean that we 
> should also model this in the mapping by subtyping?
> 
> I take the refinement to say that every abstract is also a description. 
> That matches the semantics of subtyping perfectly, as far as I can tell.
> 
> There is a discussion of some of the issues involved here:
>   http://www.garshol.priv.no/blog/115.html
> 
> ---Specific mappings
> 
> Is dc:type really the same as tmdm:type-instance?
> 
> Should dc:title really be represented using the default name type? I'm 
> asking because it seems reasonable to assume that the title is the 
> default name.
> 
> --- The type vocabulary
> 
> This reads like a list of topic types to me. Having looked through the 
> DB specs it seems like these are intended as the values for the dc:type 
> property. Should we make this more explicit? Should we state something 
> about how these are intended to be used? Of course, this depends on how 
> dc:type is mapped, but still...
> 
> --- The encoding schemes
> 
> The same questions apply here, really. These are topics in Topic Maps, 
> which sounds fine, but how are the topics to be used? Shouldn't we say 
> something about that?
> 
> ---Editorial
> 
> Scope: would it be better if we just called Dublin Core "...a vocabulary 
> for expressing document metadata..."?
> 
> 3.1: Last sentence: is "reifying topic" better than "resulting topic"?
> 
> --Lars M._______________________________________________
> sc34wg3 mailing list
> sc34wg3 at isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
> 


-- 

...........................................................................
Murray Altheim <murray07 at altheim.com>                           ===  = =
http://www.altheim.com/murray/                                     = =  ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               = =  = =

       Boundless wind and moon - the eye within eyes,
       Inexhaustible heaven and earth - the light beyond light,
       The willow dark, the flower bright - ten thousand houses,
       Knock at any door - there's one who will respond.
                                       -- The Blue Cliff Record


More information about the sc34wg3 mailing list