Liddy,
I think you are mixing up the usability of metadata tools with the
underlying structure of the metadata.  (Actually, I think we all tend to
do this at the moment because the quality of metadata user-interfaces
tends to be rather poor in many tools).  Just because we choose 3
properties in the underlying metadata doesn't mean that tools have to
present 3 boxes to the end-user.  Tools can choose to present a single
list as part of the user-interface, but then partition the end-user
selections into 3 metadata fields as necessary.

This cuts both ways of course.  As I mentioned, dc:format covers at
least three very distinct concepts (file format, physical media and
dimensions).  So a user-interface designer might choose to present 3
boxes to the end-user, but place all the resulting information into one
metadata field.

As an aside, I would argue that dc:format is a good example of poor
metadata design - i.e. its not a property that we want to copy!

So the question is *not*:

Is it better to be choosing from one list or four?

because that is a user-interface design question.  We are intersted in
the underlying structure of the metadata description.  The question is
more like:

Is it better to structure our metadata using a single very general
property with 1 (or 3) vocabularies OR using 3 more specific properties
each with a single vocabulary?

I agree that this is a design choice, and as such there are no clear-cut
answers.

But I would argue that DCMI tends to lean towards the latter route (more
specific properties).  For example, DCMI has separated out spatial
coverage ("it's about the 15th century") and temporal coverage ("it's
about Mexico") from other kinds of topics ("it's about Chemistry") by
creating several properties, rather than by simply using dc:subject with
several controlled vocabularies (which would have been the alternative
approach).

The justifaction for this approach is not easy to document - and as far
as I know, DCMI has never tried to write down guidance on where to draw
the line between using properties and vocabularies.  Two points are
worth noting though.  Firstly, where applications choose not to use
controlled vocabularies, it helps to have used more specific properties
rather than very general ones (in order that some sense can be made of
the resulting values by remote metadata systems).  Secondly, where
applications choose to define their own vocabularies, the relationship
between any term in the vocabulary and the described resource is clearer
(to remote metadata systems that don't know the vocabulary) if more
specific properties have been used.

But, as I said above, it's a design choice, and there are arguments in
both directions.

I still have a gut-feeling preference for something like

<meta name="a4a:controlMode"
      scheme="a4a:ControlCharacteristic"
      content="KeyboardOnlyControl" />
<meta name="a4a:displayMode"
      scheme="a4a:DisplayCharacteristic"
      content="Braille" />

rather than

<meta name="a4a:adaptability"
      scheme="a4a:AdaptabilityCharacteristic"
      content="KeyboardOnlyControl" />
<meta name="a4a:adaptability"
      scheme="a4a:AdaptabilityCharacteristic"
      content="Braille" />

which is what I think you are suggesting??  But as you can see from the
above, I admit that I'm struggling to put that gut-feeling into a
coherent argument! :-(

Andy
--
Head of Development, Eduserv Foundation
http://www.eduserv.org.uk/foundation/
[log in to unmask]
+44 (0)1225 474319 

> -----Original Message-----
> From: DCMI Accessibility Group 
> [mailto:[log in to unmask]] On Behalf Of Liddy Nevile
> Sent: 10 March 2006 23:56
> To: [log in to unmask]
> Subject: Re: Liddy's comments in the wiki (long and techie comments)
> 
> Andy
> 
> I think it is a matter of style, usability, etc ....
> 
> If we look at what happens with subject, we find huge vocab 
> lists. In the case of adaptability, IMHO, there is work going 
> on in many places and some of the things that might need to 
> be included in metadata now will either be transmitted 
> automatically in other ways later, some new things will 
> arise, etc. I personally think they are all just adaptability 
> attributes. In putting the a4a before them, in a sense I 
> think you are saying the same thing.
> 
> You are saying, I think, that these should be part of an 
> application profile. I think how one understands the role and 
> value of application profiles might well be a matter for 
> debate. More and more elements being useful is not what I am 
> hearing where I work - people do not want to complete massive 
> long questionnaires to add a bit of metadata and if there are 
> 4 or more additional elements, I suspect they will not be used.
> 
> As for processing - your original objection. If looking for 
> and finding values for attributes in one or four places makes 
> the difference, --- I cannot comment on that.  I do know that 
> those who have already implemented this stuff are using a 
> single element with structured values so they musty be 
> processing the values somehow?
> 
> I would like whatever to be as simple as possible for those 
> being asked to add metadata, so long as that does not cause 
> problems for those trying to implement it. I am willing to be 
> guided on that balance but do want to take account of what I 
> hear from people who will be writing this metadata.
> 
> Re your choice of categories - we have worked with 3 dimensions:  
> control, display (presentation) and content choice. These are 
> the dimensions for adaptation for accessibility, as we see 
> it. So we'd have to think from the beginning again to come up 
> with the categories you suggest (very hypothetically). I did 
> group the attributes, as you know, so they would easily be 
> remembered etc - which is what, in fact, I think of as the 
> actual role for the groupings of DC elements for me.
> 
> Let's hope to hear from others - is it better to be choosing 
> from one list or four is the question??? Does it have any 
> implications for implementers that should be noted?
> 
> Liddy
> 
> 
> On 10/03/2006, at 6:23 PM, Andy Powell wrote:
> 
> > I completely agree that the use of controlled vocabs is 
> fine and to be 
> > encouraged.  But I'm suggesting that they are used with a 
> small number 
> > of properties (perhaps 4) rather than with one single uber-property.
> >
> > So instead of having one property (a4a:adaptability) with one big 
> > controlled vocab (or 4 smaller controlled vocabs) as I 
> think you are 
> > currently suggesting, we should instead have 4 properties 
> (along the 
> > lines of a4a:perceptionMode, a4a:controlMode, 
> a4a:structuralFeatures, 
> > a4a:functionalFeatures but note that I don't understand this space 
> > well enough to know if these are correctly named), each with an 
> > associated controlled vocabulary.
> >
> > Is that clearer?
> >
> > Andy
> > --
> > Head of Development, Eduserv Foundation 
> > http://www.eduserv.org.uk/foundation/
> > [log in to unmask]
> > +44 (0)1225 474319
> >
> >> -----Original Message-----
> >> From: DCMI Accessibility Group
> >> [mailto:[log in to unmask]] On Behalf Of Liddy Nevile
> >> Sent: 10 March 2006 00:23
> >> To: [log in to unmask]
> >> Subject: Re: Liddy's comments in the wiki (long and techie 
> comments)
> >>
> >> Andy
> >>
> >> you wrote
> >>
> >>>  the problem here is
> >>> that we are looking at a fairly broad range of characteristics - 
> >>> perceptionMode, controlMode, structuralFeatures, 
> functionalFeatures 
> >>> (or somesuch).
> >>>
> >>> It is much better to separate out these characteristics
> >> using several
> >>> properties - not least because doing so will make the 
> semantics of 
> >>> each much clearer.  Otherwise we get into what I tend to
> >> think of as
> >>> the "DC Format problem".  Very different kinds of values lumped 
> >>> together in the same property.  This makes machine 
> processing very 
> >>> difficult or impossible.
> >>>
> >> I think these characteristics are independent of each 
> other but all 
> >> related to adaptability. There could be groups of them, 
> for sure, eg 
> >> control, display and presentation as we want for disability/ 
> >> accessibility, ...
> >>
> >> I think we'd prefer them to come from a controlled vocab 
> and am sure 
> >> the implementers want that ... (so the ISO version includes such a 
> >> vocab).
> >>
> >> I am not sure what you are suggesting by your comment?
> >>
> >> Liddy
> >>
>