On Wed, 1 Dec 2004, Andy Powell wrote:
> http://www.ukoln.ac.uk/metadata/dcmi/abstract-model/
>
> I've made the changes outlined below from the Arch WG meeting in Shanghai
> and one or two other bits of tidying up.
I think this looks good. I would just note one point that arose in a
previous exchange regarding related descriptions.
see point 1 in
http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0402&L=dc-architecture&T=0&F=&S=&P=367
http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0402&L=dc-architecture&T=0&F=&S=&P=483
In summary, initially the AM document states:
"The abstract model of DCMI metadata descriptions is as follows:
* The value representation may take the form of a value string, a rich
value or a related description."
then
"A number of things about the model are worth noting:
* A related description describes a related resource and is therefore
not part of the description - for example, a related description may
provide metadata about the person that is the creator of the described
resource."
These statements seem to me contradictory, or at least confusing, as to
the role of related description in the model. Also I note related
description appears as an entity in Figure 2 the DCMI description model.
Perhaps something like the following is the case?
* The value representation may take the form of a value string, a rich
value or *identification of* a related description.
Rachel
>
> --- cut ---
> - It would be better if we modelled 'syntax encoding scheme URI' and
> 'vocabulary encoding scheme URI' as separate entities in the model.
>
> - The AM currently restricts the number of parent properties that a
> sub-property can have to a maximum of one - this is an error and will be
> made unlimited.
>
> - Does the model get the definitions of simple DC and qualified DC right?
>
> - Should the model support ordered lists of values?
>
> Of these, there was quite a long discussion around the meanings of simple
> DC and qualified DC. No consensus was reached. We therefore agreed to
> remove definitions of these terms from the Abstract Model.
>
> We also discussed possibility of adding support for ordered lists of
> values to the abstract model. This requirement had been raised at the DC
> Date WG meeting the day before. However, there appeared to be little
> support for this in the room.
> --- cut ---
>
> I've discussed the process and timeline from now w.r.t. this document with
> Makx and we have agreed the following schedule:
>
> - DC-Arch review until 10 December
> - DC-Advisory Board review 20 December-20 January
> - Public comment announcement 7 February until 7 March
> - Publication Recommendation 7 March (scheduled Web site
> publication)
>
> (assuming that all goes well of course). Given that I'm slightly later
> than I wanted to be in announcing this version, I think we can afford to
> slip the first date in that list to the 14 December (which gives just
> about 2 weeks from now for the first phase).
>
> What I would like to hear before then (either in public to this list
> or privately to me or Makx) are:
>
> - suggestions for minor changes to the text prior to the AB review
>
> - comments that this document should not be moved forward in the way
> outlined above
>
> - endorsements of support for this document moving forward in the way
> outlined above
>
> Andy
> --
> Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
> http://www.ukoln.ac.uk/ukoln/staff/a.powell +44 1225 383933
> Resource Discovery Network http://www.rdn.ac.uk/
>
---------------------------------------------------------------------------
Rachel Heery
UKOLN, University of Bath tel: +44 (0)1225 386724
http://www.ukoln.ac.uk
|