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:26:31 UTC