Re: VIAF contributor model

Hi Jeff,

These mapping triples seem ok to me, at least as first sight (again, I feel always more when all stuff is presented at once, including variant representation--e.g. FOAF--and example data ;-) )

About the "contributor model" you're holding off until later: I guess the blessing and the danger here is the behaviour or having them typed as skos:Concepts in a networked environment.
You still plan to have an owl:sameAs between instances of NameAuthority and the URI coined by VIAF providers (e.g. German Natl Library), don't you? If yes, and these providers publish something that is essentially a SKOS concept then you're alright. If they publish resources for which the typing as SKOS concept is less obvious (e.g., instances of foaf:Person) then there could be some uneasiness.
It would be of course interesting to have the opinion of these providers--or to look back at their data :-)

Cheers,

Antoine


> 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 Tuesday, 9 November 2010 22:35:57 UTC