RE: VIAF contributor model

Joachim,

Unfortunately, no... At least for now.  The problem is this SKOS integrity condition on skos:prefLabel:

http://www.w3.org/TR/skos-reference/#S14


Because VIAF aggregates authority records from a variety of sources, there is no clear way to choose yet. 

Jeff

> -----Original Message-----
> From: Neubert Joachim [mailto:J.Neubert@zbw.eu]
> Sent: Wednesday, November 03, 2010 10:26 AM
> To: Young,Jeff (OR); Antoine Isaac
> Cc: public-lld
> Subject: AW: VIAF contributor model
> 
> Hi Jeff,
> 
> I suppose
> 
> > <http://viaf.org/ontology/1.1/#hasEstablishedForm>
> >  rdfs:subPropertyOf skosxl:altLabel ;
> 
> should have been
> 
> <http://viaf.org/ontology/1.1/#hasEstablishedForm>
>  rdfs:subPropertyOf skosxl:prefLabel ;
> 
> - correct?
> 
> Cheers, Joachim
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Young,Jeff (OR) [mailto:jyoung@oclc.org]
> > Gesendet: Mittwoch, 3. November 2010 14:48
> > An: Antoine Isaac
> > Cc: Neubert Joachim; public-lld
> > Betreff: 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 14:35:27 UTC