Re: VIAF contributor model

Hello Barbara, Emmanuelle

See on this question the foaf:focus property proposal.
http://wiki.foaf-project.org/w/term_focus
In the case proposed below, we would have for example
<http://viaf.org/viaf/102333412/#skos:Concept<http://viaf.org/viaf/102333412/#skos:Concept>>
foaf:focus   <http://viaf.org/viaf/102333412/#foaf:Person>

Best

Bernard


2010/11/4 Emmanuelle Bermes <manue.fig@gmail.com>

> Barbara,
>
> Thanks for joining the list!
>
> Very short summary of this interesting thread: we could use SKOS
> and/or SKOS-XL (SKOS for Labels, an extension of SKOS) for encoding
> the part in authority data that is about Names.
> We need something else for the data that is about persons and
> corporate bodies as real world objects, be it FOAF, RDA, FRAD...
>
> Which means that for the same authority record, we need to mint at
> least 2 URIs, one for the "real thing" and one for the "Name" :
> http://viaf.org/viaf/102333412/#foaf:Person
> http://viaf.org/viaf/102333412/#skos:Concept
>
> For more detail, you may want to read the thread in the list's archives
> [1].
>
> Best regards,
> Emmanuelle
>
> [1] http://lists.w3.org/Archives/Public/public-lld/2010Oct/0107.html
>
> On Wed, Nov 3, 2010 at 5:46 PM, Tillett, Barbara <btil@loc.gov> wrote:
> > 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>
> >> > > >
> >> > >
> >> >
> >> >
> >
>
>


-- 
Bernard Vatant
Senior Consultant
Vocabulary & Data Engineering
Tel:       +33 (0) 971 488 459
Mail:     bernard.vatant@mondeca.com
----------------------------------------------------
Mondeca
3, cité Nollez 75018 Paris France
Web:    http://www.mondeca.com
Blog:    http://mondeca.wordpress.com
----------------------------------------------------