partial datamodel review

Andy,

I started reviewing your document [1] for our meeting the other day. I 
didn't get all the way though it, but the following are partial 
comments. I don't know how much of this has been addressed by others on 
the DC-* lists, as I regret I haven't been able to follow discussion.

[1]   http://www.ukoln.ac.uk/metadata/dcmi/abstract-model/


1. Introduction

- "This document specifies an abstract model for Dublin Core (DC) 
metadata records"

em: I don't know what constitutes a 'record'. If there is a glossary / 
definition linking to this would be helpful

2. Terminology

general comment: shift this to an appendix and link terms in the 
document as you use them to their definitions

- element refinements can be used in metadata records independently of 
the properties they refine.

em: i believe you mean to say 'independently of the elements they 
refine.'

- In DCMI practice, an element refinement refines just one parent DCMI 
property.

em: suggest DCMI element.

general comment: you seem to be saying properties and elements are the 
same thing but are using these inconsistently in your definitions. I'm 
concerned this will be confusing to the end user

- A value results when an element or element refinement is used to 
describe a resource.

em: i think i know what you mean :) but i find this sentence confusing

- a record...

em: ah... see Introduction comment

- value URI

em: Is an 'encoding scheme URI' used to indicate that a value is a 
'value string' or a 'value URI'?

- encoding scheme
...
- vocabulary encoding scheme

em: you point out 'There are two types of encoding scheme: vocabulary 
encoding scheme and syntax encoding scheme.' but I'm not sure what 
distinguishes one from another. I'd suggest that perhaps *not* 
distingusihing these in the model makes life much simpler.

em: additionally, stating 'encoding schemes' are identified by URI's 
allows us to simplify things even more and remove the notion of 
'encoding scheme URI' definition.

... getting confused by your definitions... goes to section 3

3. Qualified DC model

- Each property is an attribute of the resource being described.

em: this is restating the definition of a property, no?

- Each property must be one of the elements or element refinements 
recommended by the DCMI

em: I think this is too strong of a requirement rather, 'at least one 
property must be one of the elements or element refinements recommended 
by the DCMI'.  These kind of statements however certainly push the 
bounds on what is considered 'DC' and what is not.


4. Simple DC model

...
- Each value has a value string.
- Each value string may have an associated value string language (e.g. 
en-GB).
...

em: This requirement is confusing to me in terms of the Qualified DC 
model section. Any element that generally takes a URI as its value 
(identifier, relation, rights) in this case is interpreted as a 'value 
string' but in the Qualified DC section would be interpreted as a 
'value URI'. 'Knowing' which way to interpret this in advance is not an 
  easy task without mining the values.


4.1. Dumb down

- Repeatedly resolve any properties to their 'parent' property (as 
indicated by the 'Refines' attribute in the DCMI Metadata Terms 
recommendation [DCTERMS]).
- Remove any resulting properties that are not one of the 15 DCMES 
elements [DCMES].

em: to clarify, resolve *any* properties (even if they are not DC* 
properties) to their 'parent' property, yes?


-----

NOTE: I think some simple / neutral formalized modeling language is 
required from this paper

--
eric miller                              http://www.w3.org/people/em/
semantic web activity lead               http://www.w3.org/2001/sw/
w3c world wide web consortium            http://www.w3.org/

Received on Friday, 19 September 2003 09:16:36 UTC