LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  May 2013

BIBFRAME May 2013

Subject:

Re: What local means, was: Authorities: updating

From:

Jörg Prante <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Sat, 25 May 2013 17:16:28 +0200

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (334 lines)

I'd like to elaborate on this a little bit, it's not really a 
Bibframe-specific thing, it's more about how information sharing on the 
Semantic Web can work for library cataloging.

I.

RDF Turtle example with anonymous resources. Only works can be linked.

Harvard:

hu:work9 a bf:Work;
     hu:author [
         a hu:Author;
         hu:label "some name here";
         hu:authority lcna:PersonA
     ] .

Stanford:

su:WorkSu7 a bf:Work;
     su:author [
         a su:Author;
         su:label "some name here";
         su:autority lcna:PersonA
     ] ;
     owl:sameAs hu:work9.

This is a perfectly valid example. The information is doubled.

By saying su:WorkSu7 owl:sameAs hu:work9, a semantic reasoner will 
assume those bf:Work resources as equal, no matter if the authors are 
equal or not (another question is if that makes sense). This could be 
asserted by another statement for property equivalence, hu:author 
owl:samePropertyAs su:author

II.

RDF Turtle example with explicit identified resources. Works and Persons 
can be linked.

Harvard:

hu:PersonF a bf:Authority;
     hu:label "some name here";
     hu:authority lcna:PersonA .

hu:Work9 a bf:Work;
     hu:author hu:PersonF .

Stanford:

su:PersonAbc a bf:Authority;
     su:label "some name here";
     su:authority lcna:PersonA .

su:WorkSu7 a bf:Work;
     su:author su:personAbc .

Now, the equivalence of two resources can be asserted by Stanford:

su:PersonAbc owl:sameAs hu:PersonF .
su:WorkSu7 owl:sameAs hu:Work9 .

or vice versa by Harvard:

hu:Work9 owl:sameAs su:WorkSu7 .
hu:PersonF owl:sameAs su:PersonABC .

This is also perfectly making sense. Each library is cataloging in its 
domain, "hu:" or "su:". Note, there is no fixed rule for declaring 
owl:sameAs by Bibframe or other institutions.

Maybe the assertion was added by a deduplication routine, maybe by 
manual editing. If both catalog departments work in parallel, one could 
say, there is duplication of work. And by consulting the RDF, the 
triples would show the "truth".

(That is when I can't resist to remember Andrew Osborn's "The Crisis in 
Cataloging", 1941, and the subsequent work of Seymour Lubetzky).

III.

The idea of having shared information by an authoritative source is 
having something like this:

lcna:PersonA a bf:Authority;
     rdfs:label "some name here" .

So Harvard and Stanford can use inferencing to get to the label "some 
name here" (and all other properties of lcna:PersonA) with a single triple:

su:WorkSu56 a bf:Work;
     su:authority lcna:PersonA .

hu:Work10 a bf:Work;
     hu:authority lcna:PersonA .

And the whole LCNA information is shared, no duplication of work.

And if Harvard wants to point to the Stanford work, because they later 
discovered the usefulness or correctness of it, they could again assert 
semantic equivalence by:

hu:Work10 owl:sameAs su:WorkSu56 .

As a consequence, when third parties will reuse catalog information from 
Harvard and from Stanford, a semantic reasoning engine will add 
information by looking at the rules for both resources, no matter if 
hu:Work10 or su:WorkSu56 is selected for reasoning.

The choice between "hu:" or "su:" can be tedious, so a union catalog 
might come handy. This would look like this:

union:WorkABC a bf:Work;
     owl:sameAs hu:Work10, su:WorkSu56 .

and for those who want to trust "union:", they can use union:WorkABC 
instead of hu:Work10 or su:WorkSu56.

These examples all make perfect sense.

Here in Germany, we have distributed union catalogs, completely unlinked 
on the work level yet, but recently linked at authority level. I'm very 
happy about GND, which was the result of unifying locally scattered 
authorities, so we now have a unified german authority catalog for 
getting started with RDA. And we are fully aware of the challenges that 
are ahead of us when more globally valid entities will be introduced.

With Bibframe and the Semantic Web, all variants will exist, they can't 
be forbidden. But the understanding of what is happening with the 
catalogs and the automatic resolving towards a "best effort" solution by 
logical rules executable by machines will be easier than without Bibframe.

Jörg


Am 25.05.13 15:09, schrieb Karen Coyle:
>
> On 5/24/13 1:01 PM, Ford, Kevin wrote:
>>> I do think that BIBFRAME should have a way to keep together an external
>>> authority identifier and the local display forms.
>> -- I don't know if I understand your point correctly, but, to me, the BIBFRAME Authority as a lightweight abstraction layer meets this need quite nicely.  It is a resource that provides a means to store local display forms and link to an external authority.
>
> I'm beginning to wonder what we mean by "local". I think that I fall 
> into thinking about local systems and what they will have, but that is 
> an assumption about the future that may not prevail. I earlier asked 
> about the re-use of BIBFRAME authorities, using the example below. The 
> primary question is: does each library holding an item mint a new URI 
> for an authority? In other words, do the 6,000+ libraries that hold a 
> copy of Harry Potter #1 each have a separate "local" URI for J K Rowling?
>
> Here's the example I gave:
>
> - There is an LCNA identifier and description for PersonA, call it
> lcna:PersonA
> - Harvard catalogs a book by that author (original cataloging). Harvard
> creates a BIBFRAME Work description and a BIBFRAME Authority, using the
> Harvard domain (call it HU). We now have:
>
> HU:Work9 -> author -> HU:PersonF
> HU:PersonF -> label -> "some name here"
> HU:PersonF -> authority -> lcna:PersonA
>
> Later, Stanford uses the HU data for copy cataloging. Does Stanford now
> have:
>
> HU:Work9 -> author -> HU:PersonF
> HU:PersonF -> label -> "some name here"
> HU:PersonF -> authority -> lcna:PersonA
>
> Or does Stanford have:
>
> SU:WorkSu7 -> author -> SU:PersonAbc
> SU:PersonAbc -> label -> "some name here"
> SU:PersonAbc -> authority -> lcna:PersonA
>
>
> That is, does the original BIBFRAME authority identity get re-used, or 
> does copy cataloging result in the minting of new URIs for each 
> entity?  (This is more a "best practice" question than a "what is 
> technically possible" question.)
>
> Then if at some later date Stanford does original cataloging for 
> another Work by PersonA, and would it create:
>
> SU:WorkSu56 -> author -> SU:Person12
> SU:Person12 -> label -> "some name here"
> SU:Person12 -> authority -> lcna:PersonA
>
> Or would Stanford re-use its own URI for that person?
>
> SU:WorkSu56 -> author -> SU:PersonAbc
> SU:Person12 -> label -> "some name here"
> SU:Person12 -> authority -> lcna:PersonA
>
> Obviously, I'm not asking what *will* happen, I'm asking what we think 
> *should* happen. And to me this is mixed in with the question of 
> "local" and what "local" means.
>
> kc
>
>>> I'm still not sure
>>> when it makes sense to link from the local BIBFRAME "authority" and
>>> other external authorities (VIAF, or national libraries in other
>>> countries).
>> -- As you surmise, ideally "national and other shared authority files would link to each other" and one could just follow the links.  But there may also be times when someone finds a source of information about a Person that may not be available via one of the links of an authority file.  So, for example (and this is off the top of my head), perhaps a German library uses the GND for its authority control for the form of a name, but then finds an alternate source for more detailed information about the Person (that is not linked to from the GND or VIAF).  That library could then link its BIBFRAME Authority resource for that Person to this additional source in order to include information from that source in its display.
>>
>> Cordially,
>> Kevin
>>
>>
>>> -----Original Message-----
>>> From: Bibliographic Framework Transition Initiative Forum
>>> [mailto:[log in to unmask]] On Behalf Of Karen Coyle
>>> Sent: Friday, May 24, 2013 2:28 PM
>>> To:[log in to unmask]
>>> Subject: Re: [BIBFRAME] Authorities: updating
>>>
>>>
>>> On 5/24/13 6:52 AM, Trail, Nate wrote:
>>> As far as "where is the link for updates", I think it would probably
>>> not be the same link, since so many flavors of update would need to be
>>> handled. A system would need to know how to interpret the link and get
>>> to the flavor of update it wants (JSON serialization of the full info,
>>> rdfxml of just the label, etc).
>>>
>>> that makes sense, Nate. And therefore it is possible that the update
>>> link may be different from the more general "authority" link. And
>>> presumably this is another area where versioning will be important --
>>> e.g. if you don't update your system from "cookery" to "cooking", that
>>> wouldn't be so much an error as an earlier version.
>>>
>>> I do think that BIBFRAME should have a way to keep together an external
>>> authority identifier and the local display forms. I'm still not sure
>>> when it makes sense to link from the local BIBFRAME "authority" and
>>> other external authorities (VIAF, or national libraries in other
>>> countries). I'm not against it, I'm just not coming up with a use case
>>> at the moment. In general, I would assume that national and other
>>> shared authority files would like to each other as a matter of course.
>>>
>>> kc
>>>
>>>
>>> Each authority would have to maintain an API for such updates.  That
>>> said, the ID link, with content negotiation, is actually a good step in
>>> that direction, since you can get all these formats of the record right
>>> there:
>>> Alternate Formats
>>> . RDF/XML (MADS and SKOS)
>>> . N-Triples (MADS and SKOS)
>>> . JSON (MADS/RDF and SKOS/RDF)
>>> . MADS - RDF/XML
>>> . MADS - N-Triples
>>> . MADS/RDF - JSON
>>> . SKOS - RDF/XML
>>> . SKOS - N-Triples
>>> . SKOS - JSON
>>> . MADS/XML
>>> . MARC/XML
>>> We do not, of course, have a push service that tracks change dates
>>> (yet).
>>>
>>> Nate
>>>
>>> From: Bibliographic Framework Transition Initiative Forum
>>> [mailto:[log in to unmask]] On Behalf Of Karen Coyle
>>> Sent: Thursday, May 23, 2013 6:34 PM
>>> To:[log in to unmask]
>>> Subject: [BIBFRAME] Authorities: updating
>>>
>>> Here is the example of a BIBFRAME Authority from the Authorities
>>> document:
>>> <Organization id="http://bibframe/auth/org/ifla">
>>>        <label>
>>>              IFLA  Study Group on the Functional Requirements for
>>> Bibliographic
>>>              Records
>>>        </label>
>>>        <link>http://www.ifla.org/</link>
>>>        <hasIDLink
>>> resource="http://id.loc.gov/authorities/names/nr98013265"  />
>>>        <hasVIAFLink resource="http://viaf.org/viaf/148620313"  />
>>>        <hasDNBLink resource="http://d-nb.info/gnd/2167628-8"  />
>>> </Organization>
>>>
>>> I still haven't an answer from an earlier question (now lost in all of
>>> this email) as to whether there will be a specific link from the
>>> BIBFRAME Authority to the actual shared authority file used by the
>>> library - that is, the file from which the library derives what here is
>>> shown as the "<label>". The example above shows links to LCNA, DNB and
>>> VIAF, but it isn't clear if any one of those is singled out as the
>>> authority being used by the library. Why does this matter? It matters
>>> because if the library intends to be part of an authority community,
>>> they have to be able to receive updates from the shared authority file,
>>> and therefore there must be a link between the shared authority file
>>> and the local usage of a term. I illustrate this in the diagrams I did
>>> at:http://kcoyle.blogspot.com/2013/05/bibframe-authorities.html  (see
>>> esp. 2nd diagram).
>>>
>>> If there isn't such a link then I do not see how libraries will be able
>>> to keep their names in sync with the authority file to which they
>>> adhere.
>>>
>>> We also haven't talked about alternate names. The examples show a
>>> single name form. Indexing requires alternates. Both single names and
>>> alternates often comes from a shared authority file (that isn't local)
>>> and both types of name forms can change. What is the link that makes
>>> change management work with the BIBFRAME Authorities?
>>>
>>> kc
>>>
>>>
>>> --
>>> Karen Coyle
>>> [log in to unmask]  http://kcoyle.net
>>> ph: 1-510-540-7596
>>> m: 1-510-435-8234
>>> skype: kcoylenet
>>>
>>>
>>> --
>>> Karen Coyle
>>> [log in to unmask]  http://kcoyle.net
>>> ph: 1-510-540-7596
>>> m: 1-510-435-8234
>>> skype: kcoylenet
>
> -- 
> Karen Coyle
> [log in to unmask]  http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager