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

FYI, In id.loc.gov we used skos:notation for codes.
Sally McCallum

-----Original Message-----
From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
Behalf Of Neubert Joachim
Sent: Wednesday, November 03, 2010 1:14 PM
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'tthink we've  
> yet got a solution for. Code lists are literallylists of codes, e.g.  
> "en" "fr" "sp" for the languages. Thecode isn't really the prefLabel, at  
> least not the userpreLabel. The codes exist because they are to be input  
> infixed-length fields (remember when saving one byte in everyrecord was  
> important?). The user display is generally thespelled out form of the  
> term, and could be available indifferent languages.
> I don't know of a way in SKOS to say: this is the standardcode for this  
> term. It's not an altLabel, it's really adifferent 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, "metadataelement" and  
> "metadata element set"
> >> seem to resonate with folks who are already somewhatfamiliar with a>>  
> data processing model. However, I worry that people willassume 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 usingmetadata.>> I  
> think it is legitimate to say that MARC does not have properties>> (in  
> the semweb sense), and there are no statements in aMARC record>> as it  
> is coded today. The advantage here is thatlibrarians can move>> to new  
> concepts and a new vocabulary about those concepts, which I>> think will  
> help keep them from dragging the old ideasalong 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 definesome other>  
> bits and pieces too, eg. instances of a class (to use as acontrolled>  
> 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 ismaking 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 18:04:14 UTC