Jon said:
===
7. The definition for "description" in terms of a "statement" has
bothered me for some time (in both versions); particularly when metadata
instances can manifest other than descriptions (in the plain english
sense) -- eg., as data that identifies or is associated with a resource.
If a resource collection is managed only by inventory codes, for
example, these codes could be said to be metadata instances but they
certainly don't "describe" a resource.
===
Sorry, I'm afraid I didn't quite understand the issue being raised here.
So, on those grounds, I should probably have left it to one of my
comrades to take a stab at an answer, but as I've started.... ;-)
The document describes a model for an information structure which it
calls a description set, and in which the thing it calls a description
is, by definition, a set of statements.
Certainly the term "description" is used in other contexts to refer to
other things which don't fit that definition, but this model doesn't
apply to those things.
Also, other forms of metadata adopt information structures which do not
take the form of description sets, do not contain descriptions,
statements etc. A LOM instance, for example isn't a description set, and
doesn't contain descriptions or statements. But this model doesn't apply
to those information structures.
I'm not sure that an inventory code itself is ever really a metadata
instance, but I guess it depends what we mean by "metadata instance.
Certainly. a collection of inventory codes isn't a description set, as
specified by the DCAM document. However, I think you could construct a
description set, containing a set of descriptions, each describing a
single resource in your collection, and each containing a statement
which referenced an inventory code.
e.g. using the DC-Text syntax that we presented at DC-2006:
DescriptionSet (
Description (
Statement (
PropertyURI ( <http://purl.org/dc/elements/1.1/identifier> )
ValueString ( "IC-0001" )
)
)
Description (
Statement (
PropertyURI ( <http://purl.org/dc/elements/1.1/identifier> )
ValueString ( "IC-0002" )
)
)
)
and so on creating a description for each resource in the collection.
So each description "says": there exists some resource, and the single
statement in each description "says" the (described) resource is
identified by the inventory code.
Certainly, those would be pretty minimal/skeletal "descriptions" in the
colloquial sense of the word, but if that is all the information we have
available, then that's fine: I think they would be perfectly good
descriptions in the sense in which the term is used in the DCAM
document.
I'm not sure whether that has addressed the concern you raised though!
;-)
Cheers
Pete
---
Pete Johnston
Technical Researcher, Eduserv Foundation
Web: http://www.eduserv.org.uk/foundation/people/petejohnston/
Weblog: http://efoundations.typepad.com/efoundations/
Email: [log in to unmask]
Tel: +44 (0)1225 474323
|