Issue 23

Eric, MacKenzie, please can I give you an action to agree on the text for
section 3.2.4?

Eric Miller writes: 

> re section 3.2.4

> The Dublin Core Initiative has indeed agreed upon a set of formal and
> agreed upon relationships for relating resources

http://dublincore.org/dcregistry/detailServlet?reqType=detail&item=http%3A%2
F%2Fpurl.org%2Fdc%2Felements%2F1.1%2Frelation

> btw... this service is one of several examples that are identified in
> section 4.4

> the point being made in the paragraph is an important one, but the
> specific example is not correct.

Eric, if I understand correctly this is the paragraph you think is
incorrect:

"Mapping between different schemas
This is more difficult than the schema versioning case since often times
different versions of the same vocabulary use common conceptualization but
this is not often true for different schemas. For example, Dublin Core has
an "item-centric" perspective on what is being described, with the majority
of the metadata pertaining to the item as a whole, while other descriptive
metadata schemas (e.g. the VRA Core schema) describe a conceptual "work" and
have many elements for describing details of the described item as well as
the whole item. Mapping between Dublin Core and VRA Core schemas is thus
challenging because of their different conceptualizations of what is being
described, and the different levels of granularity with which they describe
things. Another example is Dublin Core versus a recently developed schema
for describing biomedical images which takes as it's root the research
project which produced the images, and has in its hierarchy the concepts of
"study", "instrumentation", and finally the images themselves. Mapping
between a flat, one-size-fits-all schema like Dublin Core and something like
this biomedical image schema is simply useless, since the metadata about the
images themselves is meaningless outside the context of the other project
metadata for which there is no equivalent in the Dublin Core schema.

So although users may try to encode relationship information, they may not
do it in a consistent way. Clearly, just as when mapping between different
vocabulary versions, there are situations where it will be possible to
perform automatic mapping and situations where there is insufficient
information or the information is sufficiently ambiguous to require human
intervention. However, arguably, due to the difference in
conceptualizations, mapping between schemas is more likely to require the
later than mapping between different vocabulary versions." 

Now in fact this paragraph was proposed by MacKenzie (issue 23). The
original text for section 3.2.4 was

"Mapping between different schemas
This is more difficult than the versioning case as generally different
versions of the same vocabulary will use common conceptualization but this
is not necessarily true for different schemas. For example, METS can define
relationships between different resources. For example it is possible to
imagine a resource that is a picture, then a resource that is a photographic
reconstruction of that picture, then a resource that is a critical text
about the photograph. However other schemas, such as Dublin Core, do not
have formal ways of defining such relationships. The DC specification says: 

"The present resource may be derived from the Source resource in whole or in
part. Recommended best practice is to identify the referenced resource by
means of a string or number conforming to a formal identification system" 

So although users may try to encode relationship information, they may not
do it in a consistent way. Clearly, just as when mapping between different
vocabulary versions, there are situations where it will be possible to
perform automatic mapping and situations where there is insufficient
information or the information is sufficiently ambiguous to require human
intervention. However, arguably, due to the difference in
conceptualizations, mapping between schemas is more likely to require the
later than mapping between different vocabulary versions."

thanks, best regards

Dr Mark H. Butler
Research Scientist                HP Labs Bristol
mark-h_butler@hp.com
Internet: http://www-uk.hpl.hp.com/people/marbut/

Received on Monday, 7 April 2003 07:10:47 UTC