On Fri, 1 Jul 2005 21:12:33 +0100, Pete Johnston <[log in to unmask]> wrote:
>If we say the collection is the aggregation, and the aggregation is
>something concrete, not simply an abstract/conceptual resource (which I
>think is the argument I was making to Andrew a few minutes back!), then
>I think in that case the use of dc:format to describe a collection
>_does_ become a possibility.
>
>But I come back to my point that the relationship type that you want to
>express using dc:format in statements like
>
>collection:C dc:format _:y .
>_:y a dcterms:IMT .
>_:y rdf:value "audio/mp3" .
>
>is a different type of relationship from the one expressed by dc:format
>in
>
>file:F dc:format _:y .
>_:y a dcterms:IMT .
>_:y rdf:value "audio/mp3" .
>
>The latter set of statements gives me enough information to conclude
>that I can take the resource file:F and give it to an application that
>consumes the format "audio/mp3"; if I make that assumption from the
>second set of statements, I'm in trouble. My mp3 player can't process
>collection:C. It can process some of the items that make up
>collection:C, but that's a different thing. So it seems to me we have
>two different interpretations of dc:format in the two statements, and I
>think that is problematic.
Just to argue against myself, we've done pretty much exactly the same with
the use of dc:language and I've gone along with that so far, so I withdraw
that as an argument in principle - though I'm still uneasy about the
practical consequences of applying it to the dc:format case.
I think my initial concern was this: if an application queries a set of
Dublin Core descriptions - including descriptions of different types of
resource - for resources for which the value of dc:format is the audio/mp3
MIME type, given the definition of the dc:format property and the
dcterms:IMT class, is it appropriate that the result set includes both a
description of a collection which includes items of format audio/mp3 and an
audio file which is of format audio/mp3?
(OK, I've said too much on this thread - I'll shut up now!)
Pete
|