RE: VIAF contributor model

Gordon,

I agree that VIAF adds some awkward twists. Perhaps we could start by comparing a contributed record in FRAD vs SKOS/FOAF and worry about VIAF clustering effects later?

I poked around the FRAD RDF to try to catch up:

http://metadataregistry.org/schema/show/id/24.rdf


It looks like some effort has already gone into the FRAD model to consolidate the FR family as planned.

http://www.w3.org/2005/Incubator/lld/wiki/Library_standards_and_linked_data#Consolidated_FR_model 

My impression is that frad:BibliographicEntity (frad:C1010) and frad:Name (frad:C1006) is a reconceptualization of FRSAD Thema/Nomen. 

http://metadataregistry.org/schemaprop/show/id/1823.html

http://metadataregistry.org/schemaprop/show/id/1807.html


The domain and range on frad:isAppellationOf (frad:P2014) and frad:hasAppellation (frad:P2013) properties seems to confirm this:

http://metadataregistry.org/schemaprop/show/id/1824.html

http://metadataregistry.org/schemaprop/show/id/1825.html


Looking closer, it appears that FRAD has split the idea of frsad:Nomen into two halves: frad:ControlledAccessPoint (frad:C1001) and frad:Name (frad:C1006):

http://metadataregistry.org/schemaprop/show/id/1802.html

http://metadataregistry.org/schemaprop/show/id/1807.html


Each of these classes has its own "has type of" property: frad:hasTypeOfName (frad:P3022) and frad:hasTypeOfControlledAccessPoint (frad:P3006):

http://metadataregistry.org/schemaprop/show/id/1849.html

http://metadataregistry.org/schemaprop/show/id/1833.html


I'm concerned about the ambiguity on the range of values for these two properties:

frad:hasTypeOfName:
 skos:scopeNote "Includes personal names, corporate names, names of families, trade names, and titles of works and manifestations. Includes names of concepts, objects, events, and places."

frad:hasTypeOfControlledAccessPoint
 skos:scopeNote "Includes terms and/or codes designating the type of access point (e.g., personal name access point, family name access point, corporate name access point, meeting name access point, territorial name access point, title access point, collective title access point or access points consisting of a combination of names, such as creator/title access points)."

Assuming that Jane Austen is a frbrer:Person (http://metadataregistry.org/schemaprop/show/id/1567.html), it seems odd and redundant to have to proclaim that her frad:Name is frad:hasTypeOfName "personal name" and her frad:ControlledAccessPoint is frad:hastypeOfControlledAccessPoint "personal name access point".

Perhaps we could start with a basic use case to build up comparisons between FRAD and SKOS/FOAF? Here's where I imagine starting from a SKOS/FOAF (via VIAF) perspective:

     @prefix : <viaf/102333412/#> .
     @prefix foaf: <http://xmlns.com/foaf/0.1/> .
     @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
     @prefix skos: <http://www.w3.org/2004/02/skos/core#> .
     @prefix skosxl: <http://www.w3.org/2008/05/skos-xl#> .
     @prefix viaf: <http://viaf.org/ontology/1.1/#> .
    
    :Austen,+Jane,+1775-1817     a viaf:Heading;
         skos:inScheme <authorityScheme/SELIBR>;
         skosxl:literalForm "Austen, Jane, 1775-1817" .
    
    :Osten,+Dzjejn,+1775-1817     a viaf:Heading;
         skos:inScheme <authorityScheme/SELIBR>;
         skosxl:literalForm "Osten, Dzjejn, 1775-1817" .
    
    :foaf:Person     a foaf:Person .
    
    <viaf/sourceID/SELIBR%7C207420#skos:Concept>     a skos:Concept;
         skos:inScheme <authorityScheme/SELIBR>;
         skosxl:altLabel :Osten,+Dzjejn,+1775-1817;
         skosxl:prefLabel :Austen,+Jane,+1775-1817;
         foaf:focus :foaf:Person .

This should tells us that a person exists that SELIBR cares about. Their preferred label for this person is "Austen, Jane, 1775-1817" but they recognize "Osten, Dzjejn, 1775-1817" as an alternative. Can we come up with an "equivalent" FRAD representation?

Jeff

> -----Original Message-----
> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
> Behalf Of gordon@gordondunsire.com
> Sent: Wednesday, November 10, 2010 11:34 AM
> To: public-lld
> Subject: RE: VIAF contributor model
> 
> ​Jeff and others:
> 
> Some comments (but not much disagreement ;-) about these proposals for
> VIAF related to the FR family:
> 
> FRAD does not model the concept of "authority file" or "concept scheme"
> directly. Its focus is the class Controlled Access Point (CAP)
> (singular) and it has little to say about collections of such CAPs
> (either in a single "authority file" or an aggregation like VIAF).
> There is a rich set of relationships between CAPs (e.g. the properties
> hasAlternateScriptForm, hasDifferentRulesForm, hasParallelLanguageForm)
> but again the focus is on individual CAPs.
> 
> FRAD provides classes for Agency and Rules: Agency creates CAP - CAP is
> governed by Rules - Rules is applied by Agency. This allows a way of
> linking an Agency (what a VIAF contributor is) to a collection of CAPs
> all governed by the same Rules to model an authority file - but many
> real-world authority files contain CAPs governed by different Rules
> (e.g. AACR1 and AACR2), so I guess some form of collection description
> model would have to be applied as well. I think this is a topic for
> discussion by the FRBR Review Group when developing the consolidated FR
> model.
> 
> I don't think there is a solution to the S14 integrity constraint. In
> the context of a single authority file, S14 assumes that any single
> Rules applied to a collection of CAPs will contain a rule that supports
> the constraint; that is, any fit-for-purpose Rules must say that there
> can only be one preferred (authorised) CAP in any one language for any
> specific concept/topic. This may be the case even when the authority
> file is governed by several Rules; there would have to be some super-
> Rules for avoiding instance collisions on the preferred CAP. But unless
> VIAF is prepared to develop such a super-Rules for itself (a truly
> global undertaking), the single preferred CAP cannot be determined.
> Another way of looking at it: is VIAF really an authority file, or an
> aggregation of authority files which itself is not an authority file
> (i.e. lacks authority)?
> 
> I'm not sure how viaf:hasEstablishedForm is derived from the
> contributor data. Is it a mapping from a preferred label or authority
> heading encoded in the contributor record? If so, there are supporting
> use cases in the area of uniform/preferred titles or author-title
> headings (using the authorised CAP for the author part). Note that for
> the Jane Austen example, the three established forms are parallel-
> language/alternate script/transliteration variants of each other; the
> "form" is the same, it seems to me (illiterate in Arabic and Hebrew
> scripts). But many of the alternate forms are also
> language/script/transliteration variants of the same form ...
> 
> I remain uneasy about the use of foaf:Person. Can it really stretch to:
> 
> <foaf:Person rdf:about="viaf/100930005/#foaf:Person">
>   <viaf:isNamedBy rdf:resource="viaf/100930005"/>
>   <foaf:name>Trigger 1932-1965</foaf:name>
> </foaf:Person>
> 
> OK, it allows imaginary beings, which might be stretched to Donald Duck
> (http://viaf.org/viaf/74651110/#Duck,%20Donald), but Trigger is clearly
> a horse, not a person.
> 
> As already said, I think frad:Person (= rdaEntGr2:Person) is a sub-
> class of foaf:Agent, but not an equivalent class of foaf:Person. I
> would be much happier with VIAF using foaf:Agent (or frad:Person).
> 
> Note that a real-world person can be associated with more than one
> frad:Person (a rw person can have multiple personas). An authority
> file, depending on the Rules governing its CAPs, may collapse CAPs for
> multiple personas into a single record or may keep them separate (see
> Caroll, Lewis vs Dodgson, Charles Lutwidge in VIAF). VIAF seems to
> collapse CAPs into a single cluster record using cross-references
> between personas found in contributors' records. This looks like a
> definite dumbing-down ("see-also" relationship interpreted as "use/use-
> for"?).
> 
> viaf:Heading is an equivalent class of frad:CAP (I think). We should,
> generally, be careful about the term "name". In FRAD, a CAP is based on
> a Name or an Identifier (both frad:Name and frad:Identifier are sub-
> classes of frsad:Nomen). A CAP is usually composed of two parts: the
> name/identifier part plus some kind of qualifier needed to distinguish
> it from other CAPs based on the same name/identifier. The qualifier
> kinds include life-span dates, as in the VIAF example for Jane Austen.
> There can be substructure to both the Name which is the basis of the
> CAP name part (e.g. givenName "Jane"; familyName "Austen") and the
> bases of the CAP qualifier part
> (frbrer:hasDatesOfPerson=rdaEntGr2:hasDatesOfPerson "1775-1817" or
> rdaEntGr2:dateOfBirth "1775"; rdaEntGr2:dateOfDeath "1817"). Of course,
> everything is a label in this context ...
> 
> Cheers
> 
> Gordon
> 
> 
> 
> On 09 November 2010 at 22:04 "Young,Jeff (OR)" <jyoung@oclc.org> wrote:
> 
> 
> -->-->
> 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
>

Received on Wednesday, 10 November 2010 23:10:35 UTC