Just on this specific point:
> As for processing - your original objection. If looking for and
> finding values for attributes in one or four places makes the
> difference, --- I cannot comment on that. I do know that those who
> have already implemented this stuff are using a single element with
> structured values so they musty be processing the values somehow?
The use of "structured values" - which in the terms of the DCAM are
probably better described as "structured value strings" - is precisely
an indication that the application needs a richer, more fine-grained
data structure. The way "structured values" were typically used in DC
metadata meant that an application processing that data needed to be
able to "understand" (parse, interpret) not only the encoding of the DC
description, but also the (different) encoding of these other data
structures used as "structured values" (whether that was DCSV or an XML
format or something else).
If the consuming application didn't "understand" the format of the
"structured value" all it had was a single string that it couldn't
process further. By expressing the information which was
"buried"/"hidden" in the structured value using the constructs of the
DCAM. that information becomes "visible", processable by a DC
application.
The fact that things _can_ be done using a "structured value" isn't
necessarily an argument that they _should_ be done that way.
Pete
-------
Pete Johnston
Research Officer (Interoperability)
UKOLN, University of Bath, Bath BA2 7AY, UK
tel: +44 (0)1225 383619 fax: +44 (0)1225 386838
mailto:[log in to unmask]
http://www.ukoln.ac.uk/ukoln/staff/p.johnston/
|