Print

Print


Thanks, Francis - the archival perspective is important because it 
brings up the question: are all of our things 'same enough" to fit into 
a single definition of Work/Instance/Item?

One way to approach this is to encourage multiple "views" - the book 
people can have an Item graph that has a barcode and a note about a torn 
page; the archival folks (and art and museum folks) can have a rich item 
with dimensions, physical composition (marble, oil paint).

Where we seem to run into problems is when we try to impose a single 
model (dimensions are Instance level only) on everything.

And if this sounds like creating a lot of incompatibility, there are 
ways that we can pay attention to each other's data without getting 
involved in each other's structures, because any statement can 
potentially live comfortably in any number of graphs. (And from here on, 
we need pictures to describe this, so I'll stop.)

kc

On 1/16/15 5:57 AM, Lapka, Francis wrote:
>
> While I am sympathetic to the Bibframe desire to keep its core model 
> as simple as possible, I agree with Rob’s original assertion, 
> supporting his Option 2 (… make HeldMaterial a subclass of bf:Resource 
> …”).
>
> We shouldn’t impose the entire complexity of the FRBR/RDA models upon 
> Bibframe, but an Item is an entity with a robust set of attributes 
> that logically deserves to be a subclass of bf:Resource. As Karen 
> noted earlier, this is especially true for special collections (rare 
> books, archives, museums), where description of item-level information 
> is vital.
>
> It’s worth noting that the bf:Instance includes at least three 
> attributes that more rightly describe an Item (if we conceive of 
> Instance as a Manifestation—an abstract class): custodialHistory 
> <http://bibframe.org/vocab/custodialHistory>, immediateAcquisition 
> <http://bibframe.org/vocab/immediateAcquisition>, local 
> <http://bibframe.org/vocab/local>.
>
> Additionally, bf:Instance includes a number of attributes that are 
> equally appropriate to the description of Items, but for which no 
> equivalent is currently provided by bf:HeldMaterial. These include 
> (and there may be others): descriptionConventions 
> <http://bibframe.org/vocab/descriptionConventions> (and 6 other 
> “description…” attributes), dimensions 
> <http://bibframe.org/vocab/dimensions>, genre 
> <http://bibframe.org/vocab/genre> (for item-specific characteristics, 
> such as “Extra-illustrated copies”),hasAnnotation 
> <http://bibframe.org/vocab/hasAnnotation>, hasPart 
> <http://bibframe.org/vocab/hasPart> and partOf 
> <http://bibframe.org/vocab/partOf> (for aggregates, e.g. 
> bound-withs),preferredCitation 
> <http://bibframe.org/vocab/preferredCitation>, relatedAgent 
> <http://bibframe.org/vocab/relatedAgent> (to record former owners, etc.).
>
> Francis
>
> Francis Lapka  · Catalog Librarian
>
> Department of Rare Books and Manuscripts
>
> Yale Center for British Art
>
> 203.432.9672  · [log in to unmask] <mailto:[log in to unmask]>
>
> *From:*Tim Thompson [mailto:[log in to unmask]]
> *Sent:* Thursday, January 15, 2015 3:00 PM
> *Subject:* Re: Annotations in BibFrame
>
> The current MARC-to-BF conversion routine also embodies the kind of 
> indirection that Ray describes. If you convert a MARC record[1] using 
> LC's online converter, you will see things like this[2] (by the way, 
> the converter now offers N3 serialization--nice!):
>
> <http://bibframe.org/resources/FuE1421349519/8120033 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__bibframe.org_resources_FuE1421349519_8120033&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=t7GDkvcZa922K6iya7a6MxgVxxw7OjL0m1rPBXkflk4&m=kC64szcLGxpFh8rEsETJGTMnhOWC6UBv-9ZqGrRFZTI&s=75Y2Bg8XUBDIRh_-mi6K1pNWT11X5mKqnoRrnvQDdeY&e=>> 
> a bf:Text, bf:Work ;
>     bf:authorizedAccessPoint "Rosanvallon, Pierre, 1948- Démocratie 
> inachevée" ;
>     bf:derivedFrom 
> <http://bibframe.org/resources/FuE1421349519/8120033.marcxml.xml 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__bibframe.org_resources_FuE1421349519_8120033.marcxml.xml&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=t7GDkvcZa922K6iya7a6MxgVxxw7OjL0m1rPBXkflk4&m=kC64szcLGxpFh8rEsETJGTMnhOWC6UBv-9ZqGrRFZTI&s=Tkt8CmZ5gcNnrqodCRa3lt97l06ca8RliNS8ynEh-Ec&e=>> 
> .
>
> So, this "bf:Work" was actually derived from a MARC record. You'll 
> also find a bf:Annotation that confirms this:
>
> <http://bibframe.org/resources/FuE1421349519/8120033annotation20 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__bibframe.org_resources_FuE1421349519_8120033annotation20&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=t7GDkvcZa922K6iya7a6MxgVxxw7OjL0m1rPBXkflk4&m=kC64szcLGxpFh8rEsETJGTMnhOWC6UBv-9ZqGrRFZTI&s=Kl5dS_xAYmCzjGZkdmCzv8N-OIRqFcSV8-G-ghW_K9M&e=>> 
> a bf:Annotation ;
>     bf:annotates <http://bibframe.org/resources/FuE1421349519/8120033 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__bibframe.org_resources_FuE1421349519_8120033&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=t7GDkvcZa922K6iya7a6MxgVxxw7OjL0m1rPBXkflk4&m=kC64szcLGxpFh8rEsETJGTMnhOWC6UBv-9ZqGrRFZTI&s=75Y2Bg8XUBDIRh_-mi6K1pNWT11X5mKqnoRrnvQDdeY&e=>> 
> ;
>     bf:changeDate "2014-12-31T16:04" ;
>     bf:derivedFrom 
> <http://bibframe.org/resources/FuE1421349519/8120033.marcxml.xml 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__bibframe.org_resources_FuE1421349519_8120033.marcxml.xml&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=t7GDkvcZa922K6iya7a6MxgVxxw7OjL0m1rPBXkflk4&m=kC64szcLGxpFh8rEsETJGTMnhOWC6UBv-9ZqGrRFZTI&s=Tkt8CmZ5gcNnrqodCRa3lt97l06ca8RliNS8ynEh-Ec&e=>> 
> .
>
> The abstract Work being described here was obviously not itself 
> derived from a MARC record (that would be pretty twisted), ergo the 
> bf:Work must be something else, its own self-referential thing, 
> representing an act of description rather than a real world entity (at 
> least that's the way things have been modeled in the conversion 
> algorithm). So, BF classes are not surrogates of things, but 
> surrogates /as /surrogates? This all seems very postmodern. . . . The 
> whole problem always seems to come back to the desire to carry MARC 
> over into linked data (doomed to failure) rather than seeking to 
> remodel the bibliographic universe in light of the new vistas and 
> affordances that link data has to offer.
>
> Regarding bf:Instance and bf:HeldItem, I'm not sure I necessarily see 
> a problem with holdings info as an annotation. Setting aside the issue 
> of what a BF class actually refers to, let's assume that a bf:Instance 
> really does represent something in the real world. That something 
> would seem to be a hybrid entity (the intersection of FRBR 
> Manifestation and Item?), with both abstract and physical 
> characteristics. Why couldn't holdings and item-level information, 
> then, be construed as local overlays upon or "customizations" of a 
> general bf:Instance? Analogous, say, to a sequential human anatomy 
> chart with layered transparencies?
>
> Tim
>
> [1] http://bibframe.org/resources/FuE1421349519/marcxml.xml 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__bibframe.org_resources_FuE1421349519_marcxml.xml&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=t7GDkvcZa922K6iya7a6MxgVxxw7OjL0m1rPBXkflk4&m=kC64szcLGxpFh8rEsETJGTMnhOWC6UBv-9ZqGrRFZTI&s=auxGKV0GVMsmQ29RmZckK7y2BHROJhMNSVPcFMR_CLc&e=>
> [2] http://bibframe.org/resources/FuE1421349519/bibframe.n3 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__bibframe.org_resources_FuE1421349519_bibframe.n3&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=t7GDkvcZa922K6iya7a6MxgVxxw7OjL0m1rPBXkflk4&m=kC64szcLGxpFh8rEsETJGTMnhOWC6UBv-9ZqGrRFZTI&s=yiZxrm0-xec9a3NLJB_MlILhETJmEN0KHAbowYWFuY0&e=>
>
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>
> On Thu, Jan 15, 2015 at 10:28 AM, Karen Coyle <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
>
>     I like the "r-ball" ;-).The W3C Shapes group (the one looking at
>     vaidation for RDF) is also struggling to come up with a good term
>     for "the thing that you want to possess as a unit of information".
>     So far the words "graph" and "node" are popular among those folks.
>     A graph is just a group of triples that you are calling "my group
>     of triples for this thing I want to do." The more difficult
>     question is how to gather those triples in a machine-actionable
>     way -- and there the popular solutions are: named graphs, and
>     rdf:types.
>
>     The nice thing about the graph and node concepts is that they
>     allow you to address a more dynamic concept of what matters to you
>     in a particular context and at a moment in time. "Record" carries
>     some baggage from the time that what is a "valid record" is
>     defined once, for all records and for all time. Although database
>     technology has always allowed you to dynamically extract selected
>     bits of data from the database, (which we do in library systems
>     for displays, for example) most of us didn't think of those as
>     records, because the only record - the one record to rule them all
>     - was the MARC record. In fact, we've been messing with "records"
>     that aren't MARC for every system function, but we don't have a
>     name for them. r-ball would be perfect for those, as well.
>
>     kc
>
>
>
>     On 1/14/15 1:37 PM, Gordon Dunsire wrote:
>
>         Kate
>
>         This is a timely question.
>
>         I gave a presentation on "What is an RDA record?" at a forum
>         at ALA 2014 which essentially discusses what an RDA "thingy"
>         is (http://www.gordondunsire.com/pubs/pres/WhatRDARecord.pptx
>         <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.gordondunsire.com_pubs_pres_WhatRDARecord.pptx&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=t7GDkvcZa922K6iya7a6MxgVxxw7OjL0m1rPBXkflk4&m=kC64szcLGxpFh8rEsETJGTMnhOWC6UBv-9ZqGrRFZTI&s=Q9Qu6C07K_rg-dr8pJ850MVm8N7_f096CddN4wC7jiY&e=>
>         - has animation and notes not available in the slideshare
>         version). I expect a BIBFRAME thingy to face similar issues.
>
>         I have recently started to use the term "r-ball" for "thingy
>         record". It is best pronounced with a rolling "r" - as in
>         "Captain, the r-r-r-r-r-balls have lost expression!"
>         (apologies to Scotty) - because it can stand for record,
>         resource, RDF, RDA, and RIMMF: see http://rballs.info/
>         <https://urldefense.proofpoint.com/v2/url?u=http-3A__rballs.info_&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=t7GDkvcZa922K6iya7a6MxgVxxw7OjL0m1rPBXkflk4&m=kC64szcLGxpFh8rEsETJGTMnhOWC6UBv-9ZqGrRFZTI&s=vx_pXYzBV5M6pk8K7pzRf9SHWpBAeoyyGbmcqsHFSYU&e=>
>         for more information.
>
>         For real-world interaction with an r-ball, register for the
>         Jane-athon at ALA Midwinter!
>         (http://rballs.info/topics/p/jane/janeathon.html
>         <https://urldefense.proofpoint.com/v2/url?u=http-3A__rballs.info_topics_p_jane_janeathon.html&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=t7GDkvcZa922K6iya7a6MxgVxxw7OjL0m1rPBXkflk4&m=kC64szcLGxpFh8rEsETJGTMnhOWC6UBv-9ZqGrRFZTI&s=2LNQRtzw_hBLOO6SXXGowrA-xwQJ6e5Om9pTGn9BOWY&e=>).
>
>         Cheers
>
>         Gordon
>
>         *From:*Bibliographic Framework Transition Initiative Forum
>         [mailto:[log in to unmask]] *On Behalf Of *Bowers, Kate A.
>         *Sent:* 14 January 2015 04:17
>         *To:* [log in to unmask] <mailto:[log in to unmask]>
>         *Subject:* Re: [BIBFRAME] Annotations in BibFrame
>
>         The resource is the resource.
>
>         BIBFRAME is some metadata about the resource.
>
>         So, when you have some metadata brought together in the
>         BIBFRAME framework, what do you call this brought-together
>         metadata?
>
>         In short, is a BIBFRAME thingy called a "record" or is it
>         called something else?
>
>         Thanks!
>
>
>         Kate Bowers
>         Collections Services Archivist for Metadata, Systems, and
>         Standards
>         Harvard University Archives
>         Cambridge, Massachusetts, USA
>         voice: (617) 384-7787 <tel:%28617%29%20384-7787>
>         fax: (617) 495-8011 <tel:%28617%29%20495-8011>
>         [log in to unmask] <mailto:[log in to unmask]>
>
>         ------------------------------------------------------------------------
>
>         *From:*Bibliographic Framework Transition Initiative Forum
>         <[log in to unmask] <mailto:[log in to unmask]>>
>         on behalf of Robert Sanderson <[log in to unmask]
>         <mailto:[log in to unmask]>>
>         *Sent:* Tuesday, January 13, 2015 6:59 PM
>         *To:* [log in to unmask] <mailto:[log in to unmask]>
>         *Subject:* Re: [BIBFRAME] Annotations in BibFrame
>
>         Sorry to reply to my own message, but ...
>
>         Equally it may be helpful to consider it from the other end. 
>         What if I *do* have an identifier for the physical object? 
>         How do I link the HeldItem record-thingy* to it?  And if I
>         have an identifier already, and can associate properties and
>         relationships with it, what use is the HeldItem? :)
>
>         * Kate, the term used most often is "resource".  As in the R
>         in URI (Uniform Resource Identifier) or URL. But record-thingy
>         has a much nicer ring to it ... and the same initial letter! :)
>
>         Rob
>
>         On Tue, Jan 13, 2015 at 3:35 PM, Robert Sanderson
>         <[log in to unmask] <mailto:[log in to unmask]>> wrote:
>
>         Hi Nancy,
>
>         I'll try and explain, apologies for my lack of clarity!
>
>         On Tue, Jan 13, 2015 at 2:54 PM, Fallgren, Nancy (NIH/NLM) [E]
>         <[log in to unmask]
>         <mailto:[log in to unmask]>> wrote:
>
>         Hi Rob,
>
>         I contend that currently, according to the vocabulary, the
>         Annotation is the RWO. In particular, it has properties like
>         bf:barcode (Identification number of the physical item) and
>         bf:circulationStatus (Circulation status of an item).  The
>         holdings record does not have a barcode, nor is it an
>         annotation for that matter.
>
>         My understanding is that the HeldItem annotation corresponds
>         more or less to what we currently catalog as an item record,
>         which is not the same thing as a holdings record.  A holdings
>         record is a summary of the items held by a library that are
>         members of a particular manifestation, which may also include
>         data common to all the members.
>
>         My understanding of Holdings is, and please correct me:  A
>         collection of physical objects, owned by a single institution,
>         all of which are instances of a particular bf:Instance (or
>         frbr:Manifestation). So if you had two copies of a book, from
>         two different printings (say 2010 and 2012), you'd need to
>         have two Holdings records, otherwise when you relate it to
>         your Instance/Manifestation, you'd be inheriting the wrong
>         print date for at least one of the copies.
>
>         So this isn't what I'm talking about with respect to HeldItem
>         and I mispoke in my response to Karen :)  My experience with
>         the holdings side of the house is very limited.
>
>             My understanding is that the current holdings record more
>             or less corresponds to the HeldMaterial annotation.
>             HeldItem is a subclass of HeldMaterial (and therefore a
>             sub-subclass of Annotation). Properties like bf:barcode
>             and bf:circulationStatus are appropriate to HeldItem.  And
>             equally appropriately, HeldMaterial should not have those
>             properties.  So, I’m a little confused about what you’re
>             objections are (which is not to say that I think items are
>             well modeled in BF, just that I don’t understand your
>             response to Karen).
>
>         My objections are:
>
>         1. Annotation is not an appropriate base class for this,
>         regardless of whether it's a record or a real world object.
>
>         This is my primary concern. The thing with a barcode is not
>         "about" the Instance. There's no comment or body of the thing
>         with the barcode.
>
>         2. For the same reasons that we should not persist the notion
>         of authority records, we should equally drop the notion of
>         holdings/item records and simply identify and describe what
>         we're concerned with.
>
>         I want to be able to make assertions about books in the same
>         way that I want to make assertions about people, locations,
>         events, and all of the other things we hold dear.  Say I take
>         a photograph of the book. I want an identifier in order to say
>         <photograph> <depicts> <book> ... not <photograph> <depicts>
>         <item-record> ... that would be a very different photograph,
>         likely of a computer screen :)
>
>              If I can describe a book/Instance by saying that it has
>             an isbn, why can’t I describe an item/HeldItem by saying
>             that it has a barcode?  Why does it matter that the
>             book/Instance is not a single physical entity and the
>             item/HeldItem is? It seems to me that the HeldItem
>             annotation is simply additional description at a more
>             granular and only locally relevant level.
>
>         Sure, if the definition of HeldItem is something like "A
>         record that holds information about a particular physical
>         object that's only locally relevant" then no problem. But why
>         use linked data for something that's only locally relevant?
>         And why not simplify the definition to just "a particular
>         physical object" and describe it directly?  Practically all of
>         the current properties make sense already, it's not even a big
>         change :)
>
>         It's the same discussion that Kevin and I had about bf:Person
>         last year, and whether bf:Person, which hasAuthority an
>         Authority that identifiesRWO the real person, could actually
>         just cut to the chase and _be_ the real person.
>
>         Rob
>
>             *From:*Robert Sanderson [mailto:[log in to unmask]
>             <mailto:[log in to unmask]>]
>
>             *Sent:*Tuesday, January 13, 2015 4:02 PM
>             *To:* [log in to unmask]
>             <mailto:[log in to unmask]>
>             *Subject:* Re: [BIBFRAME] Annotations in BibFrame
>
>             Hi Karen,
>
>             On Tue, Jan 13, 2015 at 12:28 PM, Karen Coyle
>             <[log in to unmask] <mailto:[log in to unmask]>> wrote:
>
>             On 1/13/15 8:17 AM, Robert Sanderson wrote:
>
>                 I'm less concerned about exact definitions and more
>                 about the last case of HeldItem as a subClass of
>                 Annotation. Regardless of the exact definition, I
>                 suggest that it is impossible for the same resource to
>                 be both a real world physical object and a digital
>                 annotation at the same time.
>
>             This tells me that part of the definition of Annotation is
>             that the annotation body is a digital object, not a real
>             world object (RWO). And you contend that holdings
>             information is a RWO. Have I understood your meaning
>             correctly?
>
>             Almost. The annotation itself is a digital object, the
>             body could be anything. The model in BibFrame is that
>             HeldItem is a subClass of bf:Annotation, which has a
>             bf:annotationBody.
>
>             I contend that currently, according to the vocabulary, the
>             Annotation is the RWO. In particular, it has properties
>             like bf:barcode (Identification number of the physical
>             item) and bf:circulationStatus (Circulation status of an
>             item).  The holdings record does not have a barcode, nor
>             is it an annotation for that matter.
>
>                 If so, then my reply is truly in the definitions: Are
>                 there truly RWOs in library data? Library data has
>                 personal names, not persons. Book titles but not books.
>
>             Which I have previously argued is incompatible with Linked
>             Data, as it is centered around resources not strings.  Or
>             at the very least, any advantage of using Linked Data is
>             lost when you use it only as a 1:1 transliteration of
>             MARC's strings.
>
>                 Holdings data is a particularly odd one because
>                 there's a mixup between holdings (what library owns a
>                 resource and where it is located in the library) and
>                 item-level descriptive information (which is
>                 relatively rare in libraries but is primary in
>                 archives and museums).
>
>             Absolutely agree.
>
>                 Logically, there is a RWO, but illogically its
>                 physicality is described in what is defined in the
>                 cataloging rules as an abstract entity for a class of
>                 things (FRBR:Manifestation or BF:Instance). The actual
>                 physical item is often asserted solely by the presence
>                 of a barcode number. With this model, information
>                 about holdings (e.g. location) is just a digital
>                 resource that says something about another digital
>                 resource.
>
>             To return to my litmus test, what is the creation date of
>             the resource?  If it's the creation date of the record,
>             then I agree (and think the we need to change the model). 
>             If it's the printing date of the physical object, then
>             it's not the digital resource.
>
>                 The larger question is: should library catalog data
>                 address "real world objects" and, if so, what are
>                 those objects? The multi-entity models, FRBR or BF,
>                 make this an even harder question, IMO, because there
>                 is nothing that represents the whole that the RWO is.
>                 Delegating the RWO to an annotation is pretty bad; not
>                 recognizing that the library description is more than
>                 an abstraction with a bar code is worse.
>
>             If there is any thought to integrate with Archival,
>             Museum, Gallery and similar cultural heritage or memory
>             institution data, or beyond our natural partners to other
>             institutions, then we absolutely must engage with this
>             question.  If we wish to remain our own special, unique
>             and never-re-used snowflake, then we can persevere with
>             our arcane distinctions that were only ever introduced to
>             save bits due to a format designed for tape storage.
>
>             Rob
>
>             -- 
>
>             Rob Sanderson
>
>             Information Standards Advocate
>
>             Digital Library Systems and Services
>
>             Stanford, CA 94305
>
>
>
>         -- 
>
>         Rob Sanderson
>
>         Information Standards Advocate
>
>         Digital Library Systems and Services
>
>         Stanford, CA 94305
>
>
>
>         -- 
>
>         Rob Sanderson
>
>         Information Standards Advocate
>
>         Digital Library Systems and Services
>
>         Stanford, CA 94305
>
>     -- 
>
>     Karen Coyle
>
>     [log in to unmask]  <mailto:[log in to unmask]>  http://kcoyle.net  <https://urldefense.proofpoint.com/v2/url?u=http-3A__kcoyle.net&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=t7GDkvcZa922K6iya7a6MxgVxxw7OjL0m1rPBXkflk4&m=kC64szcLGxpFh8rEsETJGTMnhOWC6UBv-9ZqGrRFZTI&s=VZHVMqxa371pHXjHDZziA4G4wpPCcyeq0MwBUUi5Jx8&e=>
>
>     m:+1-510-435-8234  <tel:%2B1-510-435-8234>
>
>     skype: kcoylenet/+1-510-984-3600  <tel:%2B1-510-984-3600>
>

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