[Accessforall] [Preferences] Considerations on labels for terms

Gregg Vanderheiden gv at trace.wisc.edu
Sun Jun 9 01:54:58 EDT 2013


On Jun 5, 2013, at 2:07 PM, Gottfried Zimmermann (List) <zimmermann at accesstechnologiesgroup.com> wrote:

> Here are some thoughts on labels for (registered) terms, as promised in our call on Monday.  For now, these are just some statements, and I should probably provide some background information (probably in the call on Monday).  But I thought I post them to the list ahead of time so there is sufficient time to think about them before the next call.
>  
> I propose to discuss these statements one by one in the 24751 call on Monday.
>  
> Thanks,
> Gottfried
>  
> Statements on labels for terms:
>  
> 1.       Human-readable labels for terms are not first-class candidates for standardization (as the terms themselves are).  It should be possible to change a label (or provide additional labels) without invalidating the status of the pertinent (registered) term. 

GV: Agree.   And this fits our current model as far as I can see.
each vocabulary item will have a non-linguistic unique ID that is camelCase english term. 
each item can have as many "names" in each of an unlimited number of languages.    The can be called  "aliases" or "translations" or whatever but they are just different names or "labels" for the term.   
when used,  the programmer does not have to use ANY of these 'names' for the vocabulary item if the present it to the user -- they can 'label' it in the user interface with any other term they want to.   {this is the reason I think we should use "NAME" and not "LABEL" for #2 -- but.....  
>  
> 2.       We cannot - in general -  expect from a term submitter to provide labels for their terms in multiple languages. At most, we could require that a default textual English label and a textual English description is specified upon registration of a new term.  Other labels (in other languages) and descriptions (in other languages) will have to be provided by 3rdparties (upon demand).  
> Note: The ISO 639-3 set of language codes currently consists of 7874 items! While it is clear that we would not require labels in all of these languages, it will be difficult (and somewhat arbitrary) to select a subset of them as mandatory languages for labels.

GV: Agree
 however I think they need to supply 
	• Name
	• definition
	• value space


>  
> 3.       Labels can take many forms and variations, e.g. text, image (icons) in various resolutions, audio (earcon), video (sign language) in various resolutions.  In the same vein, descriptions can take many forms and variations (e.g. a diagram could be used to describe a term).
GV: interesting.   here  "label" seems the better term.  and I agree on images etc.      all diagrams have to be also described.  
>  
> 4.       In general, the labels for terms are application-specific like any other labels for applications.  There are various ways in which applications deal with this issue (including internationalization aspects), e.g. through resource bundles or resource sheets. 
> Note: In ISO/IEC 24752, labels (in any format) for an application are specified in (language-specific) resource sheets, which are stored on a resource server where applications can query and retrieve them.

GV:  Here you are using the other term for label.    We can have one "label" which is used in the code -- and is invisible to the user -- and another that is visible.   We shouldn’t use 'label' for both.  that is confusing.    in WCAG we used  NAME for the machine and Label for the human.    

>  
> 5.       Nevertheless, there is a value in defining “default labels” for registered terms, so that applications can use these default labels in case they don’t have any other suitable labels available. So, there should be “default resource sheets” (each in a specific language, providing labels in text format at least) which are to be maintained by term submitters and 3rd parties.  A Web-based tool would provide for easy editing and versioning.  The process for maintaining the default resource sheets should be very light-weight (probably automatic), and not require an approval committee.

GV:   I suggest that we just keep them in the database - though you can "pull them out and display them like they are a separate resource sheet.   No need to complicate things by having multiple things in different places.   Also complicated searching. 
>  



> Conclusion: Labels for terms are subject to user interface adaptation (with regard to a user’s preferences, and context of use, including the application they are used in). They should be construed as digital resources (not standardized) rather than part of a term (concept).

GV:  Not sure I follow or agree with all of the conclusion.    I DO agree with the central premise (what I think is the central premise) that there should be a stable fixed  "Unique iD" and that beyond that we do not bound what things are called.    I DO think though that we can suggest a default term -- and that people should use that if they don't have any better name/label to call it. 



>  
> ____________________________________________________________
>  
>  Gottfried Zimmermann
>  Prof. Mobile User Interaction
> Hochschule der Medien, Stuttgart, Germany
> Phone: +49 711 8923-2751
>  Email: gzimmermann at hdm-stuttgart.de
> Web: http://www.hdm-stuttgart.de/home/gzimmermann
> ____________________________________________________________
>  
>  
> _______________________________________________
> Preferences mailing list
> Preferences at lists.gpii.net
> http://lists.gpii.net/cgi-bin/mailman/listinfo/preferences

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20130609/c0d50b9d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7318 bytes
Desc: not available
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20130609/c0d50b9d/attachment-0001.bin>


More information about the Accessforall mailing list