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 Thursday, 4 November 2010 17:36:37 UTC