Print

Print



On 2/25/16 2:18 PM, Folsom, Steven wrote:
> Karen,
>
> 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.)


> 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,
> Steven
>
> 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.

kc

>
> 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] 
> <mailto:[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> 
>> <https://classificationweb.net/min/minaret?logic=0&auto=1&mod=Search&F_cn=&style=0&dashes=1&app=Auth&headings=1&F_keyword=&look=0&count=75&F_heading=Treaties&cmd=goto&fkey=Treaties_00_00_009601870_00_00&fkid=1&expand=1&table=2&query=&index=ez_heading&menu=/Auto/&auto=1&time=1456435395004>
>>
>> Texts of individual agreements or collections of agreements between 
>> two or more states, including protocols, supplements, amendments, etc.
>>
>> UF
>>
>> 	
>>
>> Accords (Law)
>>
>> 	
>>
>> Agreements, International
>>
>> 	
>>
>> Concords (Law)
>>
>> 	
>>
>> Conventions (Law)
>>
>> 	
>>
>> Final acts (Treaties)
>>
>> 	
>>
>> International agreements
>>
>> 	
>>
>> Pacts (Law)
>>
>> 	
>>
>> Protocols (Law)
>>
>> BT
>>
>> 	
>>
>> Law materials <JavaScript:Tracing('Law_20materials&expand=1',%200,%200)>
>>
>> 	
>>
>> Records (Documents) 
>> <JavaScript:Tracing('Records_20_28Documents_29&expand=1',%200,%200)>
>>
>> RT
>>
>> 	
>>
>> Travaux préparatoires (Treaties) 
>> <JavaScript:Tracing('Travaux_20pr_C3_A9paratoires_20_28Treaties_29&expand=1',%200,%200)>
>>
>> *Reference works*<image001.png> 
>> <https://classificationweb.net/min/minaret?logic=0&auto=1&auto=1&mod=Search&F_cn=&style=0&dashes=1&app=Auth&headings=1&F_keyword=&look=0&count=75&F_heading=Reference&cmd=goto&fkey=Reference_20works_00_00_0010202091_00_00&fkid=1&expand=1&table=2&query=&index=ez_heading&menu=/Auto/&auto=1&time=1456435446620>
>>
>> Works intended primarily for consultation rather than for consecutive 
>> reading.
>>
>> UF
>>
>> 	
>>
>> Reference books
>>
>> 	
>>
>> Reference materials
>>
>> 	
>>
>> Reference resources
>>
>> BT
>>
>> 	
>>
>> Informational works 
>> <JavaScript:Tracing('Informational_20works&expand=1',%200,%200)>
>>
>> NT
>>
>> 	
>>
>> Almanacs <JavaScript:Tracing('Almanacs&expand=1',%200,%200)>
>>
>> 	
>>
>> Bibliographies <JavaScript:Tracing('Bibliographies&expand=1',%200,%200)>
>>
>> 	
>>
>> Calendars <JavaScript:Tracing('Calendars&expand=1',%200,%200)>
>>
>> 	
>>
>> Catalogs <JavaScript:Tracing('Catalogs&expand=1',%200,%200)>
>>
>> 	
>>
>> Chronologies <JavaScript:Tracing('Chronologies&expand=1',%200,%200)>
>>
>> 	
>>
>> Citators <JavaScript:Tracing('Citators&expand=1',%200,%200)>
>>
>> 	
>>
>> Controlled vocabularies 
>> <JavaScript:Tracing('Controlled_20vocabularies&expand=1',%200,%200)>
>>
>> 	
>>
>> Dictionaries <JavaScript:Tracing('Dictionaries&expand=1',%200,%200)>
>>
>> 	
>>
>> Directories <JavaScript:Tracing('Directories&expand=1',%200,%200)>
>>
>> 	
>>
>> Encyclopedias <JavaScript:Tracing('Encyclopedias&expand=1',%200,%200)>
>>
>> 	
>>
>> FAQs <JavaScript:Tracing('FAQs&expand=1',%200,%200)>
>>
>> 	
>>
>> Finding aids <JavaScript:Tracing('Finding_20aids&expand=1',%200,%200)>
>>
>> 	
>>
>> Gazetteers <JavaScript:Tracing('Gazetteers&expand=1',%200,%200)>
>>
>> 	
>>
>> Guidebooks <JavaScript:Tracing('Guidebooks&expand=1',%200,%200)>
>>
>> 	
>>
>> Handbooks and manuals 
>> <JavaScript:Tracing('Handbooks_20and_20manuals&expand=1',%200,%200)>
>>
>> 	
>>
>> Harmonies (Reference works) 
>> <JavaScript:Tracing('Harmonies_20_28Reference_20works_29&expand=1',%200,%200)>
>>
>> 	
>>
>> Indexes <JavaScript:Tracing('Indexes&expand=1',%200,%200)>
>>
>> 	
>>
>> Loose-leaf services 
>> <JavaScript:Tracing('Loose_2Dleaf_20services&expand=1',%200,%200)>
>>
>> 	
>>
>> Phrase books <JavaScript:Tracing('Phrase_20books&expand=1',%200,%200)>
>>
>> 	
>>
>> Quotations <JavaScript:Tracing('Quotations&expand=1',%200,%200)>
>>
>> 	
>>
>> Repertories (Law) 
>> <JavaScript:Tracing('Repertories_20_28Law_29&expand=1',%200,%200)>
>>
>> 	
>>
>> Sayings <JavaScript:Tracing('Sayings&expand=1',%200,%200)>
>>
>> 	
>>
>> Statistics <JavaScript:Tracing('Statistics&expand=1',%200,%200)>
>>
>> 	
>>
>> Tables (Data) 
>> <JavaScript:Tracing('Tables_20_28Data_29&expand=1',%200,%200)>
>>
>> 	
>>
>> Trademark lists 
>> <JavaScript:Tracing('Trademark_20lists&expand=1',%200,%200)>
>>
>> 	
>>
>> Trivia and miscellanea 
>> <JavaScript:Tracing('Trivia_20and_20miscellanea&expand=1',%200,%200)>
>>
>> *Book reviews*<image001.png> 
>> <https://classificationweb.net/min/minaret?logic=0&auto=1&mod=Search&F_cn=&style=0&dashes=1&app=Auth&headings=1&F_keyword=&look=0&count=75&F_heading=Book%20re&cmd=goto&fkey=Book_20reviews_00_00_009929314_00_00&fkid=1&expand=1&table=2&query=&index=ez_heading&menu=/Auto/&auto=1&time=1456435475003>
>>
>> UF
>>
>> 	
>>
>> Literary reviews
>>
>> BT
>>
>> 	
>>
>> Reviews <JavaScript:Tracing('Reviews&expand=1',%200,%200)>
>>
>> NT
>>
>> 	
>>
>> Book review radio programs 
>> <JavaScript:Tracing('Book_20review_20radio_20programs&expand=1',%200,%200)>
>>
>> 	
>>
>> Book review television programs 
>> <JavaScript:Tracing('Book_20review_20television_20programs&expand=1',%200,%200)>
>>
>> Adam L. Schiff
>>
>> Principal Cataloger
>>
>> University of Washington Libraries
>>
>> Box 352900
>>
>> Seattle, WA 98195-2900
>>
>> [log in to unmask] <mailto:[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] <mailto:[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.
>>
>> kc
>>
>> 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.
>>
>>     cheers
>>     stuart
>>
>>     --
>>     I have a new phone number: 04 463 5692
>>     https://www.facebook.com/VUWLibrary /
>>     https://www.facebook.com/TKMPC <https://www.facebook.com/TKMPC>
>>
>>     ------------------------------------------------------------------------
>>
>>     *From:*Bibliographic Framework Transition Initiative Forum
>>     <[log in to unmask]> <mailto:[log in to unmask]> on
>>     behalf of Joy Nelson <[log in to unmask]>
>>     <mailto:[log in to unmask]>
>>     *Sent:* Thursday, 25 February 2016 5:11 a.m.
>>     *To:* [log in to unmask] <mailto:[log in to unmask]>
>>     *Subject:* Re: [BIBFRAME] Things I haven't seen in bibframe
>>
>>     Stuart
>>
>>     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.
>>
>>     joy
>>
>>     On Sun, Feb 21, 2016 at 3:02 PM, Stuart Yeates
>>     <[log in to unmask] <mailto:[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.
>>
>>
>>         Journals
>>
>>         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)
>>         <https://www.oclc.org/support/services/ezproxy/documentation/db.en.html%29>).
>>         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 <http://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.
>>
>>         cheers
>>         stuart
>>         --
>>         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 <http://bywatersolutions.com>
>>     Support and Consulting for Open Source Software
>>     Office: Fort Worth, TX
>>     Phone/Fax (888)900-8944
>>     What is Koha? <http://bywatersolutions.com/what-is-koha/>
>>
>>
>>
>> -- 
>> Karen Coyle
>> [log in to unmask] <mailto:[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