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

Ok, I just released the Instruments and Voices codes as skos:Concepts
(so it can be used interchangeably with the Musicbrainz instruments
list -- see: http://purl.org/ontology/mo/mit -- for use with the Music
Ontology).

http://purl.org/NET/marccodes/musperf/

It links to the Musicbrainz instrument list, id.loc.gov and dbpedia.

Comment/suggestions definitely welcome!
-Ross.

On Mon, Nov 8, 2010 at 9:12 AM, Ross Singer <ross.singer@talis.com> wrote:
> On Fri, Nov 5, 2010 at 9:51 AM, Guenther, Rebecca <rgue@loc.gov> wrote:
>
>> 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.
>>
> Ditto with the Linked MARC Codes lists:
>
> http://purl.org/NET/marccodes/
>
> (Target Audience and Form of Item terms added last week,
> Instrumentation/Voices terms to be added today!)
>
> </shameless_self_promotion>
>
> -Ross.
>> 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
>>> >
>>> >
>>> >
>>>
>>>
>>
>>
>>
>>
>> Please consider the environment before printing this email.
>>
>> Find out more about Talis at http://www.talis.com/
>> shared innovation™
>>
>> Any views or personal opinions expressed within this email may not be those of Talis Information Ltd or its employees. The content of this email message and any files that may be attached are confidential, and for the usage of the intended recipient only. If you are not the intended recipient, then please return this message to the sender and delete it. Any use of this e-mail by an unauthorised recipient is prohibited.
>>
>> Talis Information Ltd is a member of the Talis Group of companies and is registered in England No 3638278 with its registered office at Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB.
>>
>

Received on Monday, 8 November 2010 16:44:45 UTC