W3C home > Mailing lists > Public > public-lld@w3.org > October 2010

Re: VIAF contributor model

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Fri, 29 Oct 2010 17:23:50 +0200
Message-ID: <4CCAE706.6020200@few.vu.nl>
To: Karen Coyle <kcoyle@kcoyle.net>
CC: Manue <manue@figoblog.org>, public-lld@w3.org
Hi everyone

First, +1 for using SKOS in VIAF, and +1 for separating the URIs if this is required (I mean, if you feel that the two types are really disjoint, which SKOS won't say!) and linking them after with foaf:focus or something like that.

>
>> Jeff,
>>
>> This sounds like a very good approach.
>>
>> As we were discussing during the F2F, authorities are about names, and
>> not about the real thing, so it makes sense to use SKOS. SKOS is
>> perfectly fit for prefLabel, altLabel, etc. so why reinvent the wheel.
>> Then, it's also nice to be able to describe the thing that is named.
>> There, foaf:person and foaf:organisation are probably useful when it
>> comes to persons and corporate bodies, which is what VIAF is about
>> until now.
>
> If authorities are about names, and those names are what we include in bibliographic descriptions (in libraries), where in library data would foaf:person be used?
>
> (Somewhat answering my own question, I think that given this explanation, foaf:person would be used outside of the library data environment, so library authority data might link to other resources that focus on the person rather than the name. But I can't think of a place in library data would make reference to foaf:Person except, perhaps, in the administrative fields of the authority record.)


I think all this is about being pragmatic about which stuff can be re-used across different audiences/communities. Not every data in VIAF can apply to a foaf:Person, but some of it can. From this, it seems a bit a pity not to output that data that can be mapped to FOAF. Many data consumers in the SW environment using FOAF could make use of it.
Imagine that I maintain a database linking a foaf:Person Leonardo da Vinci which connects him to many places he visited/lived in. But I don't have the many versions of Leonardo's name which are in VIAF. In such case I'd be very interested in importing the VIAF data with the many names, or linking my data to the foaf:Person in VIAF via an owl:sameAs. Of course if VIAF produces already bits of FOAF that would make my task way easier.

I'm not certain VIAF does allow this specific scenario right now, but I guess you will get the idea :-)

I think the same would go with SKOS/FRAD/FRSAD, by the way. SKOS won't capture everything, but it does allow to capture a great deal of interesting stuff in a very interoperable way (SKOS is known and used by many institutions now). So it would be a pity not to export SKOS data because it does not capture everything.
Note that SKOS may be "more compatible" with FRAD/FRSAD, in the sense that intuitively I see no reason why a SKOS concept couldn't be a FRSAD nomen or FRAD authority at the same time. So different elements of these vocs could be applied to the same URI.

Cheers,

Antoine

>
>
>
>
>>
>> So, what's important is that there are 2 resources, 2 different
>> entities with each its URI : the authority (a SKOS concept) and the
>> RWO (a FOAF agent).
>> We could even add a 3rd one for the record if needed to track
>> provenance metadata (see [1]).
>>
>> As for using RDA and FRAD, maybe they will be best fit for our data in
>> the end, but this should not prevent us to still use SKOS and FOAF if
>> we want a real uptake of our data outside the library community.
>> So back to a subject we touched during the F2F : these domain-specific
>> vocabularies should find a way to link themselves to the more general
>> ones, either by declaring equivalent properties or sub classes or
>> whatever. Otherwise, it will be very difficult for implementers (like
>> VIAF) to know how to articulate them.
>>
>> One of the added values of RDF, in my view, is that
>> ontology/vocabulary producers can provide insight on mapping their
>> entities to other standards, when relevant, in a pretty simple way.
>> Which was not really the case with MARC or XML formats. This should
>> help people who own the data create constitent mappings.
>>
>> Emmanuelle
>>
>> [1] http://lists.w3.org/Archives/Public/public-lld/2010Aug/0021.html
>>
>> On Fri, Oct 29, 2010 at 5:36 AM, Young,Jeff (OR) <jyoung@oclc.org> wrote:
>>> Karen,
>>>
>>> I assume you're talking about URI hash fragments here. I'm not using
>>> "#skos:Concept" for persons, I'm using "#skos:Concept" for skos:Concepts
>>> and "#foaf:Person" for foaf:Persons. These are two separate entities.
>>>
>>> Even though I identified these separately in VIAF early on, the
>>> need/purpose of doing so was unclear to me until Martin showed me the
>>> foaf:focus property last weekend. What it means is that SELIBR, DNB, and
>>> other VIAF contributors can disagree on the identity of the skos:Concept
>>> (including preferred and alternate labels) while still agreeing (via
>>> VIAF algorithms and owl:sameAs) on the identity of "the thing".
>>>
>>> (I wish I had gotten my bachelor's degree in the engineering college
>>> rather than the business college. What is the term we alchemists should
>>> use when we mean "axiom"?)
>>>
>>> Jeff
>>>
>>>> -----Original Message-----
>>>> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
>>>> Sent: Thursday, October 28, 2010 8:46 PM
>>>> To: Young,Jeff (OR)
>>>> Cc: public-lld
>>>> Subject: Re: VIAF contributor model
>>>>
>>>> Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:
>>>>
>>>> >
>>>> > http://viaf.org/viaf/102333412/#foaf:Person
>>>> >
>>>> > http://viaf.org/viaf/102333412/#skos:Concept
>>>> >
>>>>
>>>> I don't understand why you are using #skos:Concept for Persons/Agents.
>>>> Is it because they are marked that they can also be used in subject
>>>> headings in the MARC name authorities file? Or some other reason?
>>>>
>>>> kc
>>>>
>>>> --
>>>> Karen Coyle
>>>> kcoyle@kcoyle.net http://kcoyle.net
>>>> ph: 1-510-540-7596
>>>> m: 1-510-435-8234
>>>> skype: kcoylenet
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
Received on Friday, 29 October 2010 15:24:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 29 October 2010 15:24:10 GMT