[Om3] DC metadata for content dictionaries

[Christoph LANGE]

Dear James, dear all,

On Tuesday 26 February 2008 13:38:27 Professor James Davenport wrote:
> On Tue, 26 Feb 2008, Christoph LANGE wrote:
> > generic, so it makes sense to me to reuse vocabulary from well-known
> > ontologies like Dublin Core. I found the following reasonable mappings:
>
> Absolutely right.
>
> > CDName = dc:identifier
>
> This one I am slightly dubious about (for no good reason otehr than
> suspicion): CDname has an internal meaning for us - are you sure tehre
> aren't side-effects?

Hmm, good point. I checked this again. Choosing the right data type (or in 
ontology-speak, range of property) here has two aspects IMHO, which I'll try 
to comment on:

* what you intend to express/represent
* what formal types are available to choose from

Section 2.3 of the OM 2 standard doesn't tell much about the intended purpose 
and the internal meaning of names in OpenMath. It does restrict the range of 
this property to the XML data type NCName, and this is indeed a bit more 
specific than the range of the property dc:identifier. The latter is defined 
as rdfs:Literal (see 
http://dublincore.org/documents/dcmi-terms/#terms-identifier), which in turn 
is specified as follows (http://www.w3.org/TR/rdf-schema/#ch_literal):

> The class rdfs:Literal is the class of literal values such as strings and
> integers. Property values such as textual strings are examples of RDF
> literals. Literals may be plain or typed. A typed literal is an instance of
> a datatype class. This specification does not define the class of plain
> literals.

That is, it can be typed (but optionally), but I think for OpenMath we could 
prescribe literals typed as NCName in any place where names are expected.

On the other hand, the intended purpose of dc:identifier matches the meaning 
of OpenMath names, as I understand it, quite well 
(http://dublincore.org/documents/dcmi-terms/#terms-identifier):

>   Definition:   An unambiguous reference to the resource within a given
> context.
> Comment:   Recommended best practice is to identify the resource 
> by means of a string conforming to a formal identification system.

…

> > And now that we are at it, what would you think about allowing these
> > metadata for subsections of CDs as well? That is, for CDDefinition,
> > Example, Signature, …?
>
> This I need to think about, since we have hitherto viewed a CD as being a
> monolithic object. But I'm not against it.

Of course, my view on this is influenced from collaborative authoring (and 
wikis in particular), where you prefer small chunks of text, e.g. to prevent 
conflicts. In fact, for the OpenMath support in SWiM, which I'm working on 
right now, I intend to split CDs down to the level of CMP/FMP/Example upon 
import, and to assemble them together again upon export. In such a setting, 
it does make sense to make annotations (e.g. who was the last author) to 
subparts of CDs. After all, this is already the case in OM 2 for _some_ 
annotations, if you consider the fact that a CDDefinition can contain 
Description and CDComment children.

Best,

Christoph

-- 
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701