Print

Print


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 - 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/ 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).
>
> 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]
> *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
> fax: (617) 495-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] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600