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 16:05:58 UTC