AW: VIAF contributor model

Hi everyone,

 

It’s good to see the ongoing discussion after our F2F meeting. 

 

What I miss are  some  questions about VIAF in general: 

·          What do we expect of VIAF in future? 

·          How do we and others intend to reuse the contained data? 

·          And how will VIAF obtain data of library systems in future (probably not only by harvesting approaches like today).

Never develop without UCs in mind ;-)

 

Personally I see VIAF as the centralized information system to accomplish world-wide existing authority data from libraries. So what is more important to us, the non-library world making use of this data by VIAF or do we intend the establishment of a linked data environment for the purpose of library data aggregation and alignment, or maybe both same much?

 

Actually I don’t want to discuss formats at this point but catching the discussion, SKOS is easy to use – true - but out of my point of view not enough for the aggregation and differentiation of authority data (facing persons and corporate bodies) around the world. Means we need something additional for OUR purposes to describe these entities what immediately brings us back to the FR-models (this is OUR, the library world). Quoting Gordon: “the FRAD class is a sub-class of the FRBRer class”.

 

@Jeff how much information about persons and corporate bodies would you like to provide by VIAF? I would appreciate the full spectrum of available information out of all the authority files. If so VIAF could really act as the global authority system and not only as a provider for names…

 

However, back to the formats I don’t want to discuss J foaf doesn’t have the power to reflect our comprehensive data – I thought we want to make this high quality data available for the public –if so we should have a closer look modeling the data in FRBRer, FRAD and/or RDA in parallel to the SKOS representation.

 

Cheers, alex

 

 

 

 

 

 

 

Von: public-lld-request@w3.org [mailto:public-lld-request@w3.org] Im Auftrag von Young,Jeff (OR)
Gesendet: Samstag, 30. Oktober 2010 19:40
An: Neubert Joachim; public-lld
Betreff: RE: VIAF contributor model

 

I’m happy to hear so much agreement on the VIAF contributor model. Given this, I would like to propose a VIAF aggregation model to go with it.

 

To recap the contributor model, VIAF would mint a skos:ConceptScheme URI for each “source” and a skos:Concept for each contributed “record”. This would help us clarify the http://viaf.org/ontology/1.1/#AuthorityAgency class and do away with http://viaf.org/ontology/1.1/#NameAuthority (which are effectively contributed skos:Concepts). If the source already conforms to the “contributor model”, then VIAF can reuse their skos:ConceptScheme and skos:Concept identifiers.

 

IMO, VIAF itself should be remodeled as a skos:ConceptScheme something like this:

 

<http://viaf.org/ontology/1.2/#skos:ConceptScheme>

                rdf:type skos:ConceptScheme .

 

This would allow us to do away with http://viaf.org/ontology/1.1/#NameAuthorityCluster (which are effectively VIAF skos:Concepts). For example:

 

<http://viaf.org/viaf/108389263/#skos:Concept>

                rdf:type skos:Concept ;

                skos:inScheme <http://viaf.org/ontology/1.2/#skos:ConceptScheme>.

 

As mentioned, this would allow contributed and VIAF skos:Concepts to be related (clustered) using skos:exactMatch in a hub and spoke pattern.

 

In the “contributor model”, ConceptSchemes should be free to choose SKOS or SKOSXL prefLabel/altLabel, but VIAF will probably use SKOSXL exclusively to encourage reconciliation with the FRSAD model. The http://viaf.org/ontology/1.1/#Heading and its subclasses could then go away in favor of skosxl:Label. If necessary, VIAF could produce both literal and object labels, but it would be nice if we could avoid this duplication. 

 

Regarding FRSAD, we need to beware that skos:inScheme is typically attached to skos:Concept whereas FRSAD wants to attach it to the skosxl:Label. SKOS doesn’t specify a domain for skos:inScheme, so should we discuss the need/possibility of doing both?

 

Also note that VIAF depends on its contributors for skosxl:Labels. Although the contributed skos:Concept spokes are expected to have a prefLabel, the VIAF skos:Concept hub currently has no mechanism for choosing a preference. This presumably means that all concept/label connections at the hub level will be skosxl:altLabel in the next release. We tried to solve this in version 1.1 using custom properties, but I’m skeptical this is the correct path. Consequently, they will probably be abandoned rather than updated in the next release:

 

http://viaf.org/ontology/1.1/#hasEstablishedForm


http://viaf.org/ontology/1.1/#hasXrefAlternate


 

 

Jeff

 

From: Neubert Joachim [mailto:J.Neubert@zbw.eu] 
Sent: Friday, October 29, 2010 5:47 AM
To: Young,Jeff (OR); public-lld
Subject: AW: VIAF contributor model

 

Hi Jeff,

 

+1 for your approach using skos:Concept.

 

One key advantage I see in this is that it can be adapted and used easily inside and outside the library world, with standard tools which support homegrown keyword lists or open or custom taxonomies of any kind. An important area for such tools are autosuggest services for keyword selection, hinting from skos:altLabel to skos:prefLabel, with support for skos:hiddenLabel if necessary (you can find an example implementation of such a service at http://zbw.eu/beta/stw-ws/examples/suggest.html).

 

I'd also suggest to add a skos:prefLabel to every VIAF cluster. skos:prefLabel is meant to "unambiguously represent this concept within a KOS and its applications" (SKOS Primer). Especially in the case personal names, this encourages building unique literals like "Chen, Li, 1954-" (different from "Chen, Li, 1810-1882") in VIAF or "Müller, E. 19..-.... traducteur" in BNF or "Schmidt, Hans (Musiker)" in GND.

 

If I got it right, you already did a lot of disambiguation for your viaf:Headings. Adding a skos:prefLabel to every VIAF cluster would express clear commitment to strive for uniqueness and also allow easy reuse by tools (where skosxl:Label properties are significantly more difficult to handle), and thus could be tremendously useful.

 

Cheers, Joachim

 

________________________________

Von: public-lld-request@w3.org [mailto:public-lld-request@w3.org] Im Auftrag von Young,Jeff (OR)
Gesendet: Donnerstag, 28. Oktober 2010 23:21
An: public-lld
Betreff: VIAF contributor model

 The VIAF RDF is badly in need of an update. For example, VIAF has a bad habit of assuming that “clusters” automatically map to “Person”. Upgrading it to recognize the reality of “Organization”  and perhaps a few others shouldn’t be too hard, but there are other issues worth considering.

  

 After closer inspection, it looks like the VIAF ontology <http://viaf.org/ontology/1.1/>  reinvents some key aspects of SKOS. It would be nice to start factoring out these misalignments ASAP. This group’s input on the possibilities would be greatly appreciated.

  

 Background: VIAF started out using foaf:Person for its “real world objects”, switched to skos:Concept, and was starting to wobble back to foaf:Person. At that point, the decision was made to identify both for the sake of argument:

  

 http://viaf.org/viaf/102333412/#foaf:Person


 http://viaf.org/viaf/102333412/#skos:Concept


  

 It was far from clear at the time whether both made sense, separate identity was necessary, or what property should be used to connect them. 

  

 At the F2F, Martin Malmsten (who is involved with contributions to VIAF via SELIBR) pointed out the new foaf:focus element that seems to do a very good job of rationalizing for the connection.

  

 http://xmlns.com/foaf/spec/#term_focus


  

 Like VIAF, SELIBR also coins URIs for foaf:Person and skos:Concept and this seems like a good model for other contributors and VIAF itself to follow.

  

 I’m also inclined to believe that skos:ConceptScheme should be used to differentiate different “sources” in VIAF. This could and probably should be done regardless of whether the contributors understand or publish SKOS themselves. The attached UML is intended to show how this could be conceptualized. This presumably requires some explanation, but hopefully a picture is worth a thousand words.

	 

	I’m also pretty convinced that the http://viaf.org/ontology/1.1/#Heading class needs to be bound to skosxl:Label class in some way (rdfs:subClassOf?). I don’t think it can completely go away, though, because of inconvenient restrictions on the skosxsl:prefLabel and skosxl:altLabel.

  

 Thoughts or questions?

  

 Jeff

  

 ---

 Jeffrey A. Young
 Software Architect
 OCLC Research, Mail Code 410
 OCLC Online Computer Library Center, Inc.
 6565 Kilgour Place
 Dublin, OH 43017-3395
 www.oclc.org
 
 Voice: 614-764-4342
 Voice: 800-848-5878, ext. 4342
 Fax: 614-718-7477
 Email: jyoung@oclc.org