RE: VIAF contributor model

Barbara,

For the sake of comparison/contrast, VIAF will support skos:prefLabel/altLabel alongside rdaGr2:preferred/variantNameForTheFoo properties for naming purposes. IMO, we need to support both because closed-world models like FR/RDA need to interoperate with increasingly popular open-world models like SKOS/FOAF/BIBO. Using skos:Concept/skos:ConceptScheme/foaf:focus as higher-level abstractions should make this possible.

Jeff

> -----Original Message-----
> From: Tillett, Barbara [mailto:btil@loc.gov]
> Sent: Wednesday, November 03, 2010 12:46 PM
> To: Young,Jeff (OR); Neubert Joachim; Antoine Isaac
> Cc: public-lld
> Subject: RE: VIAF contributor model
> 
> VIAF intentionally is to link the preferred forms of names for entities
> from around the world, so there will be several linked "preferred
> names" depending on the cultural environment
> (language/script/cataloging rules/policies) from which the contributed
> data comes.  Hopefully each can be clearly identified by extensions to
> the URIs so machines will know which to prefer/choose for display in
> various contexts.
> 
> Is SKOS really the right way to go for names of persons or corporate
> bodies?  It seems strange to me, but I'm hoping to learn more from all
> of the conversations. (Sorry I just joined the list yesterday!) -
> Barbara Tillett
> 
> -----Original Message-----
> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
> Behalf Of Young,Jeff (OR)
> Sent: Wednesday, November 03, 2010 10:35 AM
> To: Neubert Joachim; Antoine Isaac
> Cc: public-lld
> Subject: 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 Monday, 8 November 2010 22:33:17 UTC