> 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.

All,

Andy's posting to dc-accessibility about "where to draw the
line between using properties and vocabularies" addresses a
design issue we have acknowledged and discussed several times
before, but I also do not recall that we ever wrote down or
even ever articulated the problem more clearly than here.

Maybe it would help to give this issue a handle, like "Semantic
specificity options".  For completeness, those options would
need to distinguish between term declarations and application
profiles.  The options might look something like the following:

1. Instead of using one broader property, use multiple,
   semantically more specific properties (i.e., declared
   in term declarations).

2. Use a broad property and specify its values with
   vocabulary encoding schemes (i.e., declared in term
   declarations).

3. Use a broad property but restrict its definition, domain,
   range, or use in an application profile.

Listing the options and discussing advantages and drawbacks of
each -- discussing data design versus user-interface design,
uncontrolled values versus use of controlled vocabularies --
would be a useful addition to the suite of documents DCMI
offers to designers of application profiles.

Tom


On Sat, Mar 11, 2006 at 09:25:57AM -0000, Andy Powell wrote:
> 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
> > >>
> > 

-- 
Dr. Thomas Baker                                 [log in to unmask]
Director, Specifications and Documentation
Dublin Core Metadata Initiative