Looking back at the functional requirements, I think the logo could
(arguably) be of use for either "the identification of a known
collection [or] the selection of one or more collections from amongst a
number of discovered collections".
However, I agree with Pete that the Logo property is somewhat anomalous
in the way it addresses these requirements. Count me as another voice
for removing it from the the CDAP.
If we persist in including it, I would prefer Pete's reveised, tighter,
definition, on the grounds that the original has semantics so loose that
you could include any association and therefore a wide range of logos.
Most associations of logo and collction won't actually serve to meet the
functional requirements - if we include the property, I think it should
be limited to the scenarios that are relevant to the AP as a whole.
John
John Roberts
Group Manager, Archives Management
Archives New Zealand
PO Box 12 050
Wellington
NEW ZEALAND
email: [log in to unmask]
phone: +64 4 496 1392
mobile: +64 21 776 232
-----Original Message-----
From: DCMI Collection Description Group
[mailto:[log in to unmask]] On Behalf Of Pete Johnston
Sent: Monday, 15 August 2005 11:08 p.m.
To: [log in to unmask]
Subject: Re: Definition for logo property
Andrew,
> How would people search on a logo property? I'm not sure I see and
> relevance in having a 'logo' proerty for discovery purposes.
I don't think it is useful for searching (but OTOH, I don't think we've
limited ourselves strictly to information which will be
searchable/searched).
The only value I can see for it is to provide something that can be
displayed as part of a result set. I guess if I was pushed I might make
an argument that it assists identification by a human consumer of the
metadata, but I'm not sure I'd make that argument with much vigour ;-)
Personally, I think its inclusion in the profile is anomalous and I'm in
favour of removing it: if implementers of collection description
services want a logo/brand/thumbnail/whatever-they-want-to-call then
they can include one in their own application profile, but it's not
(IMHO) a property that is "core" to the functional requirements we set
out to address.
Pete
|