W3C home > Mailing lists > Public > public-lld@w3.org > February 2011

Re: New BNB sample data available

From: Simon Spero <ses@unc.edu>
Date: Wed, 9 Feb 2011 12:07:23 -0500
Message-ID: <AANLkTikBgMFaZqVYMUwyaoje1Cgy=GzHxqxZD7-b7s6c@mail.gmail.com>
To: "Young,Jeff (OR)" <jyoung@oclc.org>
Cc: Antoine Isaac <aisaac@few.vu.nl>, Karen Coyle <kcoyle@kcoyle.net>, "ZENG, MARCIA" <mzeng@kent.edu>, public-lld <public-lld@w3.org>
In the specific case of VIAF it would is almost safe to treat established
forms as preferred labels (if Getty is treated as  a transnational

However, because of the (commented) constraint that if something is  skosxl
prefLabeled by a Label, that thing is skos prefLabeled  by the literal form
of the label.  Since skos only allows one pref Label  per language per
resource, this approach doesn't really work for the issue of linguistic
register which is the problem Karen is addressing.

I am not sure if established form is best described as a sub property of
altLabel;  altLabel is roughly equivalent to 4XX  which are hasXrefAlternate
in viaf as linked to, whereas establisedForm is roughly equivalent to 1XX ,
which roughly maps to prefLabel in SKOS.

Since there is no minimum cardinality for prefLabel, it may be better to:

   1. Create a non-specific skos-xl:label relationship analogous to to
   rdfs:label .
   2. Assert that skos-xl:{pref,alt,hidden}Label are sub properties of
   3. Make hasEstablishedForm a sub property of skos-xl:label
   4. Define properties for all attributes of Label, which, if they are
   different for two labels, allow both labels to be the established forms of
   the same Thing. This probably includes reifying the  language of the label.
   5. Specify  HasKey on the Label using these properties (roughly
   equivalent to defining identity conditions on Label.
   6. Specify that hasEstablishedForm is Inverse Functional.

(I think I might be missing a step; I need to check and see what the
reasoners say).

Received on Wednesday, 9 February 2011 17:07:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:27:43 UTC