AW: VIAF contributor model

Hi Jeff,

Thanks for the hint to the updated RFC. 

> My sense is that "dnb", "bnf", and the others should be 
> broken down by language, region, and script to be useful for 
> outsiders. 

That would be great, but I'm not sure how much of it is achievable. AFAIK, the German PND does not store this information (maybe Alexander or Lars can correct me here). And I don't how much you can get out of other authorities. If it is possible to recognize script programmatically, this would be quite helpful, but I see no chance to get reliable information about language and region, if it's not provided explicitely by the source. So, to answer Karens question, plain "x-dnb", "x-bnf" etc. would only reflect the assigning agency, who developed this particular "documentation language".

> Would people be willing to consider skos:inScheme as an 
> alternative? I know this property is usually used to connect 
> skos:Concepts to skos:ConceptSchemes, but why couldn't we use 
> them with skosxl:Labels also?

A combination of skosxl:Label and skos:inScheme isn't prohibited, as you write. But it would not help for the - in my eyes highly useful - skos prefLabel/altLabel pattern, so a user/application programmer would have to rely on viaf:#hasEstablishedForm.

With skos prefLabel, it should be possible to develop a general algorithm which for example asks for a prefLabel in a preferred language, or, if no preferred language is definied, for any prefLabels (ignoring language tags) and choosing an arbitrary prefLabel if more than one is returned. Such an algorithm could be configured with an (possibly empty) list of preferred languages set per value vocabulary. 

This should work for different skos value vocabs. It demands knowledge of the languages used in the value vocabs, but no knowledge of other special features of each vocab. That's the reason why I like plain skos prefLabel/altLabel for e.g. data input supported by autosuggest/autocomplete lists.

Cheers, Joachim



> -----Ursprüngliche Nachricht-----
> Von: Young,Jeff (OR) [mailto:jyoung@oclc.org] 
> Gesendet: Mittwoch, 3. November 2010 16:30
> An: Neubert Joachim; Antoine Isaac
> Cc: public-lld; Felix Sasaki
> Betreff: RE: VIAF contributor model
> 
> Joachim,
> 
> Note that RFC 4646 has been replaced with RFC 5646 (BCP-47).
> 
> http://tools.ietf.org/html/rfc5646

> 
> My sense is that "dnb", "bnf", and the others should be 
> broken down by language, region, and script to be useful for 
> outsiders.
> 
> Would people be willing to consider skos:inScheme as an 
> alternative? I know this property is usually used to connect 
> skos:Concepts to skos:ConceptSchemes, but why couldn't we use 
> them with skosxl:Labels also?
> 
> <http://example.org/label/1>
>  a skosxl:Label ;
>  skosxl:literalForm "Shakespeare" ;
>  skos:inScheme <http://example.org/scheme/bnf> .
> 
> Notice that the domain on skos:inScheme is undefined:
> 
> http://www.w3.org/TR/skos-reference/skos.html#inScheme

> 
> Jeff
> 
> > -----Original Message-----
> > From: Neubert Joachim [mailto:J.Neubert@zbw.eu]
> > Sent: Wednesday, November 03, 2010 11:10 AM
> > To: Young,Jeff (OR); Antoine Isaac
> > Cc: public-lld; Felix Sasaki
> > Subject: AW: VIAF contributor model
> > 
> > Hi Jeff,
> > 
> > have you considered to use "private use" language subtags 
> (e.g. x-dnb, 
> > x-bnf etc., as described in 
> http://www.rfc-editor.org/rfc/rfc4646.txt

> > 2.2.7) for discriminating prefLabels by language?
> > 
> > This could be helpful to preserve statements about preferred terms 
> > made by the contributors, and could also allow VIAF users to choose 
> > one contributors preferred labels over the others.
> > 
> > I vaguely remember a discussion about a similar issue some time ago 
> > and forward this mail to Felix, who may have been involved in this 
> > discussion.
> > 
> > Cheers, Joachim
> > 
> > 
> > > -----Ursprüngliche Nachricht-----
> > > Von: Young,Jeff (OR) [mailto:jyoung@oclc.org]
> > > Gesendet: Mittwoch, 3. November 2010 15:35
> > > An: Neubert Joachim; Antoine Isaac
> > > Cc: public-lld
> > > Betreff: 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 16:48:47 UTC