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 Wednesday, 3 November 2010 17:14:11 UTC