RE: Code lists / was: AW: SemWeb terminology page

In the case of the ISO 639 code lists, it would require agreement by the ISO 639 Joint Advisory Committee to specify a preferred label (and given past experience this becomes highly political), since we have not standardized the language names-- we say that the standard is for the code, which represents a language. If you look at ISO 639-2 for instance (http://www.loc.gov/standards/iso639-2/php/English_list.php), there are many cases of alternative names in the same language. In the future the maintenance of these standards is going to a database structure and it has been proposed that we do what you suggest to provide preferred labels. However, that work is under development. 

And to followup on a previous message from Karen Coyle that said:
"The codes exist because they are to be input in fixed-length fields (remember when saving one byte in every record was important?). The user display is generally the spelled out form of the term, and could be available in different languages."
This is not exactly true-- there are a number of ISO standards for coded data (countries, languages, scripts, currencies) that are widely used in all user communities internationally. The purpose is to identify a country, language, etc. with an identifier (the codes are considered to be identifiers) so that it identifies the entity, not a name for that entity, since there will be multiple names, whether in the same language or different language. In what we are doing with id.loc.gov, we are using the code i.e. identifier as the last piece in the URI.

Rebecca

Rebecca S. Guenther
Senior Networking & Standards Specialist
Network Development & MARC Standards Office
Library of Congress
101 Independence Ave SE
Washington, DC 20540
voice: +1.202.707.5092
fax: +1.202.707.0115
rgue@loc.gov

-----Original Message-----
From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On Behalf Of Neubert Joachim
Sent: Thursday, November 04, 2010 1:36 PM
To: Ford, Kevin; Karen Coyle; public-lld
Subject: AW: Code lists / was: AW: SemWeb terminology page

Hi Kevin,

Thanks for the hint - I was not aware of code lists with different labels for the same code (in a given language).

However, for some applications even in this case it may be helpful to construct a prefLabel, e.g. 

skos:prefLabel "nl  Dutch / Flemish"@en

in order to support users in the selection of values from a lookup list.

Cheers, Joachim


> -----Ursprüngliche Nachricht-----
> Von: Ford, Kevin [mailto:kefo@loc.gov]
> Gesendet: Donnerstag, 4. November 2010 17:04
> An: Neubert Joachim; Karen Coyle; public-lld
> Betreff: RE: Code lists / was: AW: SemWeb terminology page
> 
> Dear Joachim,
> 
> Your example looks good, and it would be the method I'd recommend, but 
> without the skos:prefLabel compliment if dealing with ISO 639-1, 
> 639-2, or 639-5.  For example, for the ISO 639-1 code "nl", both 
> "Dutch" and "Flemish" are valid English labels [1], but the standard 
> does not indicate which is preferred.  The ISO 639-2 code "arn" is 
> another good example of this.
> 
> The code itself would appropriately be a skos:notation, as you 
> suggest.
> 
> Best,
> 
> Kevin
> 
> [1] http://www.loc.gov/standards/iso639-2/php/code_list.php
> 
> 
> ________________________________________
> From: public-lld-request@w3.org [public-lld-request@w3.org] On Behalf 
> Of Neubert Joachim [J.Neubert@zbw.eu]
> Sent: Wednesday, November 03, 2010 13:13
> To: Karen Coyle; public-lld
> Subject: Code lists / was: AW: SemWeb terminology page
> 
> Could skos:notation help with code lists?
> 
> E. g.
> 
> skos:notation "en"^^xsd:string ;
> skos:altLabel "English"@en, "Anglais"@fr ;
> 
> possibly complemented by
> skos:prefLabel "en  English"@en, "en  Anglais"@fr ;
> 
> 
> Cheers, Joachim
> 
> > -----Ursprüngliche Nachricht-----
> > Von: public-lld-request@w3.org
> > [mailto:public-lld-request@w3.org] Im Auftrag von Karen Coyle
> > Gesendet: Mittwoch, 3. November 2010 17:45
> > An: Dan Brickley
> > Cc: Mark van Assem; Haffner, Alexander; public-lld
> > Betreff: Re: SemWeb terminology page
> >
> > Quoting Dan Brickley <danbri@danbri.org>:
> >
> >
> > >
> > > I also hear "code list" from Geo people lately (as well
> as moves to
> > > encode these in SKOS btw).
> > >
> > >
> >
> > Yes, although code lists provide another catch that I don't think 
> > we've yet got a solution for. Code lists are literally
> lists of codes,
> > e.g. "en" "fr" "sp" for the languages. The code isn't really the 
> > prefLabel, at least not the user preLabel. The codes exist because 
> > they are to be input in fixed-length fields (remember when
> saving one
> > byte in every record was important?). The user display is generally 
> > the spelled out form of the term, and could be available in
> different
> > languages.
> >
> > I don't know of a way in SKOS to say: this is the standard code for 
> > this term. It's not an altLabel, it's really a different kind of 
> > beast.
> >
> > kc
> >
> >
> > >> The analogy to properties is "data elements" in the
> traditional IT
> > >> world. In fact, the MARC documentation refers to the fields and 
> > >> subfields as data elements. For that reason, "metadata
> > element" and "metadata element set"
> > >> seem to resonate with folks who are already somewhat
> > familiar with a
> > >> data processing model. However, I worry that people will
> > assume that
> > >> a property is the same as a data element.
> > >>
> > >> The terms "property," "value" and "statement" have no
> meaning for
> > >> folks in the library world. These are new concepts, and
> should be
> > >> introduced as representing a new way of creating and using
> > metadata.
> > >> I think it is legitimate to say that MARC does not have
> properties
> > >> (in the semweb sense), and there are no statements in a
> > MARC record
> > >> as it is coded today. The advantage here is that
> > librarians can move
> > >> to new concepts and a new vocabulary about those
> concepts, which I
> > >> think will help keep them from dragging the old ideas
> > along with them into the semantic web.
> > >>
> > >> Therefore (after all of that), I would vote for using
> > 'value vocabularies'
> > >> and 'properties' ('set of properties' for something like foaf or 
> > >> dcterms?), but explain them in terms of controlled lists
> and data
> > >> elements, emphasizing the differences.
> > >
> > > Just a nitpic: most/many RDF vocabularies (DC, SKOS, FOAF
> at least)
> > > describe classes of thing as well as property terms;
> Agent, Image,
> > > Document etc. The fancier ones (in OWL often) also define
> > some other
> > > bits and pieces too, eg. instances of a class (to use as a
> > controlled
> > > value...), or to express rules. So 'set of properties'
> > captures 2/3 of
> > > what FOAF or DC or SKOS define. 'Set of property and class terms'
> > > captures pretty much everything, unless a vocabulary is
> > making heavy
> > > use of OWL.
> > >
> > >> Yep, easier said than done.
> > >
> > > Can't argue there :)
> > >
> > > Dan
> > >
> >
> >
> >
> > --
> > Karen Coyle
> > kcoyle@kcoyle.net http://kcoyle.net
> > ph: 1-510-540-7596
> > m: 1-510-435-8234
> > skype: kcoylenet
> >
> >
> >
> 
>

Received on Friday, 5 November 2010 21:34:50 UTC