RE: VIAF contributor model

Antoine,

I like your suggestion to update the current VIAF ontology with subclass/subproperty to "standard vocabularies".

Here is a mockup of some triples I imagine adding to the next ontology version:

<http://viaf.org/ontology/1.1/#AuthorityAgency>
 rdfs:subClassOf foaf:Organization .

<http://viaf.org/ontology/1.1/#NameAuthorityCluster>
 rdfs:subClassOf skos:Concept .

<http://viaf.org/ontology/1.1/#Heading>
 rdfs:subClassOf skosxl:Label .

<http://viaf.org/ontology/1.1/#hasEstablishedForm>
 rdfs:subPropertyOf skosxl:altLabel ;
 rdfs:domain <http://viaf.org/ontology/1.1/#NameAuthorityCluster> ;
 rdfs:range http://viaf.org/ontology/1.1/#Heading .

<http://viaf.org/ontology/1.1/#hasXrefAlternate> 
 rdfs:subPropertyOf skosxl:altLabel .
 rdfs:domain <http://viaf.org/ontology/1.1/#NameAuthorityCluster> ;
 rdfs:range <http://viaf.org/ontology/1.1/#Heading> .

I will hold off on adding the following "contributor model" triples until later.

<http://viaf.org/ontology/1.1/#NameAuthority>
 rdfs:subClassOf skos:Concept .

<http://viaf.org/ontology/1.1/#clusters> 
 rdfs:subPropertyOf skos:exactMatch .

Jeff

> -----Original Message-----
> From: Antoine Isaac [mailto:aisaac@few.vu.nl]
> Sent: Monday, November 01, 2010 12:16 PM
> To: Young,Jeff (OR)
> Cc: Neubert Joachim; public-lld
> Subject: Re: VIAF contributor model
> 
> Hi Jeff,
> 
> I'm not sure that everyone agreed explicitly with the "contributor"
> model. We agreed on using SKOS with other required stuff, but if you're
> going to have this perspective combined with another one, maybe we
> should re-visit our judgments ;-)
> 
> In fact the present VIAF vocabulary is good in the sense that it keeps
> explicit track of what VIAF does with the original data. There is this
> aggregation process going on, and it may be harmful to have this mis-
> represented in the data. It will be cumbersome to have the aggregated
> "local" concepts and the one resulting from the aggregation together,
> especially if both have the same type. Which one should a data consumer
> focus on?
> 
> I won't be too detailed here, as I don't think my understanding on your
> complete new proposal is precise enough. Two general remarks, though:
> 
> - in the Europeana Data Model [1] we use ORE proxies [2] in a way that
> can deal with your aggregation problem. This is fairly cumbersome,
> though. Apparently there's no free lunch on trying to solve this :-)
> 
> - as mentioned in my previous mail, hatever be your modelling decision,
> I'd favour an approach to vocabulary interoperability that relies on
> explicit subclass/subproperty (or equivalent class/property) axioms to
> standard vocabularies. Directly letting your current VIAF constructs
> "go away" (if I understand well that expression) seems dangerous, as it
> hides the original rationale of the data. Linking back to our
> application profiles discussion last week, keeping explicit your
> positioning VIAF as an AP of SKOS/FOAF/whatwever seems good :-)
> 
> Cheers,
> 
> Antoine
> 
> [1] http://version1.europeana.eu/web/europeana-

> project/technicaldocuments/, see "EDM Data Model Primer"
> [2] http://www.openarchives.org/ore/1.0/datamodel#Proxies

> 
> > 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 <http://www.oclc.org>
> >
> >     Voice: 614-764-4342
> >     Voice: 800-848-5878, ext. 4342
> >     Fax: 614-718-7477
> >     Email: jyoung@oclc.org <mailto:jyoung@oclc.org>
> >
>

Received on Wednesday, 3 November 2010 13:48:37 UTC