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

[Lars Marius Garshol]

* Lutz Maicher
>
> [datatypes]
>
> According to the latest DCMI Abstract Model recommendation (which I
> refer now) [1] so called "syntax encoding scheme URIs" should be
> assigned to "value strings" which are intended to be read by human
> beings. I think, these encoding schemes are very similar to the  
> property
> [datatype] we have in variant or occurrence items (in TMDM). Some of
> these encoding scheme URIs are proposed in the DC vocabulary
> specification [2].

I take this to mean that you think we *should* specify the datatypes.  
Did I get that right?

> The purpose of this topic map to free all topic maps authors from  
> the burden to represent any of these information in a topic map  
> which only wants to represent some metadata.

I think that's a useful thing to have. I'm not sure I care much  
whether we include something like it as part of the specification, or  
whether we leave that for third parties (like you) to do.

> Generally, this topic map should also disclose commonly used syntax  
> encoding schemes.

How?

Actually, this brings up another issue: should the specification  
include a TMCL schema for Dublin Core?

> [subtyping]
>
> In my opinion, all information about the "refinmentness" of a term are
> in the scope of the DCMT-topic map. The authors only use the term, and
> whenever any information about the relationship of the used term to
> other terms are in interest, the DCMT-topic map can be requested.

The bigger question is whether the specification should take the leap  
and say that what DCAM calls "refinement" is what we call  
"subtyping". From what you write, it seems like you think it should.  
I agree with that.

The second question is whether to include these statements in some  
kind of standard TM like the one that has the labels. I think if  
there is such a topic map it should have this (like you write above).

> [Is dc:type really the same as tmdm:type-instance?]
>
> No at all. I propose, to represent the "dc:type" property equally  
> to all
> other properties. One might argue, that a tmdm:type-instance
> relationship can be added informative.

Why do you think it is not the same? What is the difference? It's  
useful to know you don't think they are the same, but it would be a  
lot more useful to know *why* you think so. Can you give an example  
of a case where it would be inappropriate to translate

   x dc:type y

into

   x tmdm:type-instance y

?

To take one obvious example, opera.ltm says

   opera.ltm dc:type topicmap

Wouldn't type-instance be equally correct here?

See http://www.ontopia.net/omnigator/models/topicmap_complete.jsp? 
tm=opera.ltm

> [Should dc:title really be represented using the default name type?]
>
> For this property the same argument holds. We should represent this
> property equally to all other properties. And names can be added
> informative as base name.

Why should we represent it the same way? And what then happens with  
the default-typeness of titles? You'd be a lot more persuasive on  
this if you gave a rationale. :)

> [type vocabulary]
>
> Yeap. The type vocabulary should be used as value for the dc:type
> property. As we will define "guidelines for the usage of DC vocabulary
> in Topic Maps" we have to make it explicit how a value of a specific
> property should be represented. This issue is even discussed in the  
> paper.

Ok, so we agree on this.

--Lars M.