RE: VIAF contributor model

Thanks for all the feedback. Sorry for my lag following up.

 

VIAF still needs to deliver more substance to fulfill its potential, but the next release should improve interoperability while adding support for foaf:Organization/rdaEnt:CorporateBody. Mockups of Jane Austen and Die deutsche Nationalbibliothek are attached. 

 

As suggested back at the start of this thread, SKOS will play a core infrastructure role in the next release. Each contributor will be modeled as a skos:ConceptScheme and every contributed record will be modeled as a skos:Concept in the contributor’s scheme. The contributed concept URIs coined by VIAF will be based on the contributor’s “record” ID and will behave by redirecting to the VIAF cluster to which it is matched (which could change over time). 

 

Here is a test system URI for a contributed SELIBR record (207420) to demonstrate:

 

http://test.viaf.org/viaf/sourceID/SELIBR|207420#skos:Concept


 

Tangent: IMO, Library Linked Data authority systems in the future SHOULD be based on skos:ConceptScheme/skos:Concept and we’re starting to see this with LCSH and SELIBR. I suspect that ANY skos:ConceptScheme could potentially be viewed as an “authority system” and clients should be able to use them as such without assuming any architecture or domain model dependencies.

 

For VIAF contributors that choose to follow the SKOS model in their own domains, VIAF should map to their URIs using owl:sameAs. You can observe this in the attached example for Jane Austen involving SELIBR:

 

<http://viaf.org/viaf/sourceID/SELIBR%7C207420#skos:Concept>

skos:inScheme <http://viaf.org/authorityScheme/SELIBR> ;

owl:sameAs <http://libris.kb.se/resource/auth/207420#concept> .

 

I suspect there will be some concern that VIAF is coining “alias” URIs, but I would argue that intentional HTTP URI aliases play a *functional role* in Linked Data by decentralizing information *about* the thing. SELIBR can deliver its information about “the thing” from its URI and VIAF can deliver more (especially linking) information from its URI. The information may come from different perspectives and yet the players mutually agree it’s the same “real world” thing they’re describing.

 

The solution for the http://www.w3.org/TR/skos-reference/#S14 integrity constraint for skos:prefLabel on “clusters” is still unclear to me and thus won’t be addressed in the next release. (Sorry.) The custom properties viaf:hasEstablishedForm and viaf:hasXRefAlternate properties will continue to be used for now although the use cases for them are unclear.

 

Nevertheless, I want to align the VIAF ontology with SKOS/SKOSXL wherever possible and so the viaf:Heading class will be upgraded to skosxl:Label in the ontology like so:

 

viaf:Heading rdfs:subClassOf skosxl:Label .

 

In deference to FRSAD, the next release of VIAF will continue to treat labels (i.e. viaf:Headings) as 1st class identifiable resources at the expense of using plain literals. Without practical use cases, I’m uncomfortable with this choice.

 

Jeff