Any thoughts on this please?
On Sun, 10 Apr 2005 19:52:57 +0100, Pete Johnston <[log in to unmask]>
>I'm conscious that we still have not resolved the issue of how to
>describe the format of items in the collection (see e.g. ), and it is
>now urgent that we find a solution.
>I think the use of dc:format as a property of the collection for this
>would _not_ be appropriate, because if I do a search like (using SPARQL
>PREFIX dc: <http://purl.org/dc/elements/1.1/>
>PREFIX dcterms: <http://purl.org/dc/terms/>
>WHERE (?thing dc:format ?format)
> (?format rdf:value "text/html")
>I expect to retrieve a list of resources of format text/html. A
>collection that includes items of format text/html is not itself a
>resource of format text/html.
>As I said in that previosu message, I think ideally the "right" way to
>represent this would be something like:
>collection:C some:contains item:I .
>item:I dc:format format:F .
>format:F rdf:value "text/html" .
>But if we are trying to stick to using properties only of the
>collection, the only way I can think of representing this information
>would be to define a property something like cld:itemFormat
>Label: "Item Format"
>Definition: The physical or digital form of an item within the
>Comment: Recommended best practice is to select a value from a
>controlled vocabulary (for example, the list of Internet Media Types
>[MIME] defining computer media formats).
>N.B. This would _not_ be a refinement/subproperty of dc:format.
>In DC CD AP, the property would be repeatable. As for when it should be
>deployed (does the existence of one RTF document in a collection of
>99,999 PDF documents mean that I should say the collection contains PDF
>items?), I guess we'd have to provide some guidelines.
>I do wonder whether this is bending the "one-to-one rule" rather more
>than I feel comfortable with, but I don't have any better suggestions.
>Any thoughts please?
>If we did adopt this approach, then
>(a) I think we should re-consider the type vocabulary and use something
>like an itemType property with the DCMI Type Vocabulary for the types of
>the items (as suggested by Ann at ) (but we would retain the use of
>dc:type with the other types that distinguish the types of
>(b) I'm not convinced we need to retain the separate use of dc:format in
>the DC CD AP (which is rather vaguely defined/described at present):
>size would be covered by dcterms:extent, and the format of items would
>be covered by this new property.
>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]