[Om3] DC metadata for content dictionaries

[Professor James Davenport]

On Tue, 26 Feb 2008, Christoph LANGE wrote:
> On Tuesday 26 February 2008 13:38:27 Professor James Davenport wrote:
> > On Tue, 26 Feb 2008, Christoph LANGE wrote:
> > > 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.
I'll leave this ot the XML-zealots. 
> 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.
As Paul has said, isn't is Name+base, or are you regarding Base as what DC 
calls context?
> > > 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.
Fair comment. This comes down to one's view of 'unity'. I had assumed a CD 
to be essentially a unity, designed and edited as a whole.
But this may be my being old-fashioned.
James