On 2/25/16 2:18 PM, Folsom, Steven wrote:
[log in to unmask]" type="cite">

I would be interested to hear your thoughts on subclassing W/I's. Do we need the assertions to be formal subclasses? Why wouldn't multiple type assertions work (forgive the pun)? For example:

ex:Thing a bf:Work , lcgft:Almanac . # where lcgft:Almanacs isn't formally a bf:Work subclass 

Yes, that could be done. And that's quite neat because the lcgft already exists, and surely there are other schemes from other communities that would be useful as well. They would have to be declared as classes. This does require you to code both the bf:Work and the (whateverElse) class(es), but that's not a huge burden. However, even within the genres, it probably makes sense to look at whether some structural relationship between genres isn't logical. We have a flat list now, but I think that's because we couldn't use relationships between genres in our "old world." If we have "tactile text" and "text" wouldn't it be logical to treat all things coded as tactile text to also be texts? A subclass relationship would be a logical way to do that.

The other option, which may be useful in some but not all cases, is what I believe you mean by "formal subclasses":

lcgft:Almanac rdfx:subClassOf bf:Work

This wouldn't preclude you also using terms that are not subclassed to work. I see this more as a statement of the semantics than a question of efficiency or even "correctness". It would allow you to infer from Almanac that you have a Work.

I'm sure that there are advantages and disadvantages of both methods. I think it's worth considering.

I believe I said this before on this list (or some other list), but FRBR work is a very abstract concept, and I have a hard time seeing it as something that one would want to instantiate except in rare cases. Most of the time instead you have something more specific, and that is a genre -- a type of work -- which is a property in FRBR. I'm suggesting that rather than being a property it could be a subclass of work, that is, a type of work. It would have workness by inference, but it was also be more specific than just "work" which I don't think is terribly useful.

Why make those genres subclasses rather than properties? Or, conversely, what is the advantage of having a generic work with a property for genre rather than some number of work types? I have questions, no answers, and would love to hear what others think.

(Note: subclassing FRBR entities is what FaBIO did, even though I find their division of the universe a bit odd, but that was clearly their intention. See: http://kcoyle.net/frbr/?page_id=94.)

[log in to unmask]" type="cite">
Hopefully in future modeling we provision for a single method to note content types (either through bf:Work subclassing or multiple type assertions using existing vocabularies). [And *not* also bf:Category.]

Thanks in advance for your thoughts,

P.S. *warning FAST propaganda ahead*

Genre/content type access was the impetus for work we did at Cornell to implement FAST in our catalog; OCLC's LCSH to FAST algorithms give relatively nice 655's. It provided a nice reclamation process for form/genres to answer to the historic/varied practice Adam describes happening MARC.

Yes, I love the idea of FAST even though I haven't actually gotten to use it. I was hoping that it would be possible to algorithmically define a good number of genres even though our practice has not been consistent, and you seem to be saying that there is a respectable success rate. That's all we need to get started.


[log in to unmask]" type="cite">

We soon found other utilities for our FAST implementation, e.g. 

- Controlled headings/entities for what use to be 653 keyword access in minimum level cataloging

- Catalogers have even gone on record as having the "freedom" to say things they couldn't using LCSH

- The "entification" challenges Roy described got easier (at least for subjects) during MARC to RDF conversions because of the $0's. 

On Feb 25, 2016, at 4:28 PM, Adam L. Schiff <[log in to unmask]> wrote:

Karen wrote: “But we don't let them choose between a treaty, a reference book, and a book review. That information may be discernible from the bibliographic data, but it isn't presented in a usable way. At best it's hidden in a sub-section of a subject heading which a user only sees in a long display.”


Actually, RDA has the element Form of Work (MARC 380), and we have the non-RDA entry in MARC Index Term--Genre/Form (MARC 655).  BIBFRAME has places for both of them.  So we actually already have two places to record that one thing is a treaty, another is a reference book, and another is a book review.  And we even have LC Genre/Form Terms already established for each of these things.


Treaties  <image001.png>

Texts of individual agreements or collections of agreements between two or more states, including protocols, supplements, amendments, etc.


Accords (Law)


Agreements, International


Concords (Law)


Conventions (Law)


Final acts (Treaties)


International agreements


Pacts (Law)


Protocols (Law)


Law materials


Records (Documents)


Travaux préparatoires (Treaties)



Reference works  <image001.png>

Works intended primarily for consultation rather than for consecutive reading.


Reference books


Reference materials


Reference resources


Informational works














Controlled vocabularies










Finding aids






Handbooks and manuals


Harmonies (Reference works)




Loose-leaf services


Phrase books




Repertories (Law)






Tables (Data)


Trademark lists


Trivia and miscellanea



Book reviews  <image001.png>


Literary reviews




Book review radio programs


Book review television programs



Adam L. Schiff

Principal Cataloger

University of Washington Libraries

Box 352900

Seattle, WA 98195-2900

[log in to unmask]

(206) 543-8409

(206) 685-8782 fax


From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: Thursday, February 25, 2016 1:14 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Things I haven't seen in bibframe


Stuart, this is a great example of ambiguous things with the same title. What I think we are missing is better use of bibliographic types (which I think should be subtypes of WEMI or bf:WI, but that's another discussion) to help disambiguate. There's a big difference between the treaty, the reference book about the treaty, and the reviews of the reference book about the treaty, which could be facilitated by taking the bibliographic type into account. I'm not sure that really helps the cataloger, but it could be a great boon to the user.

Right now, we show users physical formats and publishing patterns: book, journal, journal article, CD, DVD, ebook, etc. But we don't let them choose between a treaty, a reference book, and a book review. That information may be discernible from the bibliographic data, but it isn't presented in a usable way. At best it's hidden in a sub-section of a subject heading which a user only sees in a long display.

Identifiers (ISBN, DOI) will distinguish between these documents for machine processing, but other qualities are needed for the human information seeker.


On 2/24/16 4:00 PM, Stuart Yeates wrote:

Maybe an concrete example might help explain one of the obvious issues with authority control of works:

We have a constitutional document here called the "Treaty of Waitangi". The original  "Treaty of Waitangi" has been around forever, so there's no problem finding URLs for authority control (WorldCat, NLNZ, Wikipedia, etc) for the work. Wise catalogers will use multiple of these URLs and they be used to crosswalk these authorities.

Claudia Orange publishes a print reference book called "The Treaty of Waitangi" about the constitutional document. Catalogers have no problem describing that this reference work is about the constitutional document, using any of the URLs for the constitutional document as a subject works fine. The print book goes into the queue for cataloging in the national bibliography.

Several journals publish book reviews. Some of these are digital-only with turnaround times measured in days or weeks. Many of these review the book in an article with the same name as book being reviewed.

The journal vendors need to produce metadata for these book review articles. Describing the work being reviewed is challenging because:
(*) we now have three identically-named abstract works by three separate authors
(*) the book reviews are being published (and largely consumed) weeks or days after the publication of the print work but the print book can take months or years to get 'properly' cataloged (national bibliography, worldcat, etc. )
(*) the book and the various book reviews are published by completely independently

Note 1 In this specific case ISBN can be used for an identifier, but of course (a) that's not linked data and (b) that can't be done for the many related cases where the work doesn't qualify for an ISBN, qualifies but has not been issued with an ISBN or has been issued with multiple ISBNs.

Note 2 RDF essentially lacks the ability to negate, so there is no way that I know of to say "There is a work called 'Treaty of Waitangi' by Claudia Orange. There is a work called 'Treaty of Waitangi' created in 1840. These two are not the same work." A clear method and requirement for doing that would at least make catching some classes of mistakes easier.


I have a new phone number: 04 463 5692
https://www.facebook.com/VUWLibrary / https://www.facebook.com/TKMPC 


From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of Joy Nelson <[log in to unmask]>
Sent: Thursday, 25 February 2016 5:11 a.m.
To: [log in to unmask]
Subject: Re: [BIBFRAME] Things I haven't seen in bibframe



A large chunk of what you talk about strikes me as a version of what I call "Closed Linked Data".  Data that is accessed through publishers/vendors have very unique requirements and access control issues.  I have seen some bibframe vocabulary that relates to this, but I would imagine this in area ready for exploration.

As far as separating complex works such as The hitchhikers guide to the galaxy, I'm not sure exactly where the confusion lies in your existing catalog.  Although I will say that is my issue with many catalogs--too many records for a few things, some relate and some are separate.  But in a bibframe or linked data world, you would have (for example) 2 URIs for The hitchhikers guide to the galaxy.  One for the book and another for the movie.   The annotations (i.e. reviews) would be their own URI tied to either the URI for the book or the movie - whichever was appropriate. 

I'm not sure this explains it well as I may not have had a great understanding of your initial concern here. I would encourage you to play with the BF tools on the LOC site.  Those tools helped me start to see how thing were connected.





On Sun, Feb 21, 2016 at 3:02 PM, Stuart Yeates <[log in to unmask]> wrote:

I attended the recent bibframe talk given by Kevin Ford at the NLNZ where in the question time and discussion afterwards we had some robust conversations which were limited by the time available.

What it seemed to boil down to was my perception that all of the bibframe work I'd seen centered on monograph-like works and pre-digital methods of acquiring and holding bibliographic works rather than the much more complex kinds of works, acquisition and holding currently in use.

Kevin's suggestion was that I post to the list with my concerns. Thus this post, which attempts to capture some of the things I've not seen in bibframe (which doesn't necessarily mean that they haven't been done, I'll admit I've not been following the list as I might recently). It reflects only me and my thoughts, not my institution.


As an academic library, we purchase many academic journals as packages. Each package is associated with a license. Each package contains one or more date-ranges of one or more journals. Each journal may be digitised for some date ranges and born-digital for others. Each journal date range consists of a number of issues. Each issue consists of a number of articles. Journals which are peer-reviewed contain at least some peer-reviewed articles, but may also contain bibliographically and academically important non-peer reviewed articles (i.e. http://www.nature.com/nature/journal/v485/n7396/full/485041e.html ) and retractions. Many journals also expose internal metadata (dates of submission, etc).

Packages are purchased from vendors and held on platforms. Vendors may subsume one another. Platforms may merge, split or collapse. Platforms may vanish, systematically breaking links (as http://www.metapress.com/ appears to have done). For some date ranges of some journals we have third party preservation arrangements (http://www.portico.org/) Platforms may require access mechanisms (IP addresses, complex proxy stanzas (https://www.oclc.org/support/services/ezproxy/documentation/db.en.html)). Content on some platforms is available end-to-end over privacy-preserving HTTPS connections, other platforms use some HTTPS but HTTP for doi resolution, some use pure HTTP. Platforms may or may not have various interoperable methods for statistics gathering (http://www.niso.org/workrooms/sushi etc).

Platforms have various policies and capabilities for having their content exposed to and reused by third parties and tools acting on our behalf, for example discovery systems to harvest full text, citation counters and journal rankers, etc.

That's a stack of complexity, particularly considering I've left out some purely internal dimensions (funding streams, institutional restructuring, audit trails, exchange rate tracking, etc).

Patron-driven acquisition

Patron-driven acquisition involves us surfacing digital titles we don't own as search results to our users and then purchasing those titles when a user makes a certain amount of use of the title (first access, first N pages, etc, etc).  Patron-driven acquisition is important because it breaks the implicit assumption that records in our library catalog are the records of 'our' holdings. Due to patron driven acquisition, we handle and ingest many more bibliographic items that we are likely to 'hold' in a traditional sense.

Certain vendors are giving presentations which portray this as an existential crisis for "The Catalog". While they are of course completely, utterly wrong, initiatives such as bibframe silently ignoring things such as PDA isn't helping dampen the flames of speculation.

Authority control

Authority control for people is has been discussed for bibframe (mainly VIAF and orcid.org). Authority control for is broader than that, however, and almost certainly needs to be done for serials and probably individual works.

https://scholarlyoa.com/other-pages/hijacked-journals/ is a list of apparent attempts to profit (directly or indirectly) from the current confusion in naming academic journals. Proper authority control is the only solution I can see to this.

It's also not clear to me how to separate complex works, For example the consider the multiple works known as  "The hitchhikers guide to the galaxy" or "The Tales of Beedle the Bard". This is related to an ongoing issue we have in our discovery system: where a (book/film) review and the work being reviewed have the same name, endless confusion ensues. I'm assuming that authority control would be used to do this kind of disambiguation, but a concrete example would be very useful.

I hope this helps.

I have a new phone number: 04 463 5692
https://www.facebook.com/VUWLibrary / https://www.facebook.com/TKMPC


Joy Nelson

Director of Migrations

ByWater Solutions
Support and Consulting for Open Source Software
Office: Fort Worth, TX
Phone/Fax (888)900-8944

What is Koha?

Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600