 |
 |
Apologies again for stepping in late... I'm inclined to agree with Ann that "logo" seemed to jarr when I read through the AP so I question its presence, though I understand completely the desire for it. dc:description seems the safest location given the looseness of the definition - people may choose an image that includes the collection name and a sense of the contents, or it may just be a pretty picture with no text included chosen at random to differentiate it amongst a list of collections. If it were to be under dc:title or dc:identifier, there would need to be a more specific scope/definition. I think it would be useful to add a comment that it is expected to be a URL to an image file (if that is the intention - I suppose it could be a sound logo??) so it would negate the need for dcterms:DCMIType=Image. Also the encoding scheme URI should be added to the AP. I'm thinking now that maybe it _is_ valid to include logo if we decide it is part of dc:description - resource discovery is allowed to include a description to assist the user to identify/select, why can't that description be visual? dc:description with encoding scheme URI isn't strong enough - that could just be a link to a webpage containing a description. Now "thumbnail" is quite a common concept, maybe it would be better to have a dcterms:thumbnail (refines dc:description) than cld:logo?? The DC CD AP would then call dcterms:thumbnail "logo". Douglas >>> [log in to unmask] 18/08/04 23:07:24 >>> Leaving aside for a moment the issue of whether or not we include a "logo" property in DC CD AP, two points highlighted by this discussion: Firstly, FWIW, it occurred to me that given (i) the comment/usage note for dc:description: > Description may include but is not limited to: an abstract, table of contents, > reference to a graphical representation of content or a free-text account of > the content. and (ii) the fact that DCMI provides refinements for the first two cases (dcterms:abstract, dcterms:tableOfContents), it would seem logical to provide a refinement for the third case, e.g. dcterms:graphicalRepresentation. (But unless we need it for DC CD AP, I'm quite happy to keep quiet!) Secondly: > However if the group does decide there should be a logo > property, then I would go for dc:description with an encoding > scheme of dcmitype:Image. This could be extended to allow eg > audio with dcmitype:Sound, etc. The only drawback to this > seems to be that if the encoding scheme is dcmitype:Image > then there is no way to also say that the value is a URI, but > maybe that is implicit. This is a problem with the current DC-in-XML encoding (and its use of xsi:type) that has been highlighted by the work on the Abstract Model and which I've been grappling with. I'm writing up some notes on problems with the DCMI XML Schemas at the moment so I'll add this as an issue. > If we go this route, then maybe this only needs to be stated > in some guidelines associated with the AP rather than a > formal property within the AP. > > Another reason to be wary of including a logo property is > that it opens up further even more specific display requests > such as size, alternative text, etc. Such things seem to me > to be out of scope of the DC CD. They would be metadata about the image so (given our current scope - attributes of the collection) we could sidestep them on those grounds (though yes, I agree that implementers of the DC CD AP would almost certainly want to provide information like that). Pete