Peter - There is one simple answer to your question, which requires
reference to other bits of the DC spec. That is - follow the 1:1 rule.
This says that the metadata must describe a single instantiation of
the resource. If that has been derived from another instantiation
somehow, then use "Relation" (or maybe "Source" - we're still
finalising the semantic distinctions between these ...) to indicate
the ancestors, etc, which will each have their own separate DC metadata.
It is, however, very important to keep the distinction between
Type and Format quite clear - Type gives the genre, and
would not normally change through watermarking, compression,
etc. Your sentence "Is the resource defined in terms of the
underlying type or the final type." seems to make an error here.
Nevertheless, your question raises some issues regarding the handling
of *Format* information which certainly demand attention, exemplified
by compression.
In many cases resources are posted on the net as compressed
files (eg zip) in which case the format of the current
instantiation is MIME-type application/zip.
However, that information is not really enough for a client to use.
Most every system can unzip stuff now, but then you'll discover that
what is inside the zip file is something with yet another format,
eg a Wintel exe (application/???) file (as much self-extracting
software is distributed) or TEX (text/vnd.latex-z), or tar, or something.
And inside the tar file are other files with other formats, maybe a
unix src tree complete with Makefiles, and links to particular libraries
only available on certain flavours of Unix, etc etc.
And the exe, tex or tar file or whatever is not actually available
separately, so there is no existing resource to point to
with DC.Relation (though it can be generated)!
Clearly, in this (and presumably other) cases we need to be able to
indicate these "nested" formats of the digital resource (regardless
of the underlying genre or DC.Type). The simple DC repetition
mechanism can be used to include multiple DC.Format elements,
corresponding to the various MIME-types nested in a single
resource. This is available in "simple" DC.
However, this is not entirely adequate since the nesting-sequence
matters - we need more structure! This is certainly something that
should be considered in qualified or structured DC, and we must
ensure that ways of expressing these semantics are developed
using the mechanisms provided by the RDF datamodel.
Peter Lambert wrote:
>
> It is not clear from the recommendations how a 'modified' resource might be
> handled. By this I mean a basic form that has been encrypted, compressed,
> password protected, watermarked or in some other way modified, without
> changing the basic type of the resource, but possibly also requiring
> processing at the user end. Is the resource defined in terms of the
> underlying type or the final type. For example, if the resource is given as
> an image type and the format is compressed (.zip) then the user is not
> informed of the processing requirements to get the image. Alternatively, if
> the type of software or data is used to indicate that the resource requires
> some form of processing (uncompress) then how is the underlying resource
> identified to the user.
>
> It might be appropriate to put these kinds of considerations into the
> dscussions about multiple components, however, the self extracting compress
> file would seem to offer a special case. The software resource only exists
> as an envelope for another resource type. It includes the unwrapping
> mechanism and this may not be a problem for a user (although a firewall
> might have some difficulty) who gets the resource type they want, in less
> time.
>
> The question is can a user know from the existing single Types and Format
> if they are getting a modified file, what that modification is, and what
> processing requirements (if any) are necessary.
--
__________________________________________________
Dr Simon Cox - Australian Geodynamics Cooperative Research Centre
CSIRO Exploration & Mining, PO Box 437, Nedlands, WA 6009 Australia
T: +61 8 9389 8421 F: +61 8 9389 1906 [log in to unmask]
http://www.ned.dem.csiro.au/SimonCox/
|