- From: Eric Miller <em@w3.org>
- Date: Fri, 19 Sep 2003 09:16:32 -0400
- To: Andy Powell <a.powell@ukoln.ac.uk>, Stu Weibel <weibel@oclc.org>
- Cc: www-archive@w3.org
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