RE: VIAF contributor model

Jeff
 
Here's my attempt at an FRAD representation:
 
@prefix : <viaf/102333412/#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix frad: <http://iflastandards.info/ns/fr/frad/> .
@prefix frbrer: <http://iflastandards.info/ns/fr/frbr/frbrer> .
 
:Austen,+Jane,+1775-1817 a frad:ControlledAccessPoint;
  frad:isCreatedBy <http/SELIBR>;
  frad:hasBaseAccessPoint _:Austen,+Jane;
  frad:hasAddition "1775-1817";
  frad:hasDesignatedUsageOfControlledAccessPoint "Preferred";
  frad:hasParallelLanguageForm :Osten,+Dzjejn,+1775-1817 .
 
_:Austen,+Jane a frad:NameOfAPerson;
  frad:hasNameString "Austen, Jane" ;
  frad:isAppellationOf _:frbrer:Person:Austen,+Jane ;
  frad:hasTypeOfName "Personal name" [1] ;
  frad:hasDatesOfUsage "1775-1817" [2] ;
  frad:hasAlternativeLinguisticFormPerson _:Osten,+Dzjejn .
 
:Osten,+Dzjejn,+1775-1817 a frad:ControlledAccessPoint [3];
  frad:isCreatedBy <http/SELIBR>;
  frad:hasBaseAccessPoint "Osten, Dzjejn";
  frad:hasAddition "1775-1817";
  frad:hasDesignatedUsageOfControlledAccessPoint "Alternate".
 
_:Osten,+Dzjejn a frad:NameOfAPerson;
  frad:hasNameString "Osten, Dzjejn";
  frad:hasTypeOfName "Personal name" [1];
  frad:hasDatesOfUsage "1775-1817" [2] ;
  frad:hasAlternativeLinguisticFormPerson _:Austen,+Jane [4] .
 
_:frbrer:Person:Austen,+Jane a frbrer:Person ;
  frbrer:hasNameOfPerson _:Austen,+Jane [5] ;
  frbrer:hasNameOfPerson _:Osten,+Dzjejn [5] ;
  frbrer:hasDatesOfPerson "1775-1817" [6].
 
Notes:
 
[1] Cannot be inferred from: _:Austen,+Jane  a frad:NameOfAPerson. The category
may have a different semantic from frbrer:Person.
[2] Assuming life-span dates are in scope.
[3] Can be inferred from: _:Austen,+Jane frad:hasAlternativeLinguisticFormPerson
_:Osten,+Dzjejn .
[4] Can be inferred from: _:Austen,+Jane frad:hasAlternativeLinguisticFormPerson
_:Osten,+Dzjejn .
[5] Can be inferred (in consolidated FR model) from: _:Austen,+Jane 
frad:isAppellationOf _:frbrer:Person:Austen,+Jane ;
[6] A specific instance of frad:Rules would govern the relationship between the
values for frad:hasDatesOfUsage and frbrer:hasDatesOfPerson, and whether either
is to be used as the value of frad:hasAddition.
 
Note also that the frsad namespace is irrelevant to this example, and that the
FRAD model preceded the FRSAD model.
 
Cheers
 
Gordon
 

On 10 November 2010 at 23:09 "Young,Jeff (OR)" <jyoung@oclc.org> wrote:

> 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
> >