Print

Print


Hi Jeff,

On Tue, Jan 13, 2015 at 7:36 PM, Young,Jeff (OR) <[log in to unmask]> wrote:

>  From a Linked Data POV, a thingy and its description SHOULD (not MUST)
> be separately identified.
>

But if a URI identifies a thingy, it MUST NOT also identify its
description. Otherwise Tolkien starts authoring metadata records
posthumously, and that's not a good look :)


> Thingy identifiers (http URIs) SHOULD (not MUST) be bound to descriptions
> identifiers (http URIs) via HTTP 303 redirects.
>

Agreed. Best practice (e.g. SHOULD) is 303. 2NN doesn't have sufficient
traction to make it through the IETF, and there's enough pushback to the
redirect adding latency and thereby cost that HTTP-Range-14 is going to be
with us for a long time yet.

None of which is any reason not to separately identify the things
themselves.

Thingy identifiers CAN (not MUST) be reconciled across systems using a
> owl:sameAs or schema:sameAs property, regardless of differences in how the
> thingies are described.
>

Sure. There's varying degrees in value of such reconciliation when the
descriptions are widely divergent.

Rob



>  Jeff
>
> On Jan 13, 2015, at 6:00 PM, Bowers, Kate A. <[log in to unmask]>
> wrote:
>
>   One question strikes me as germane to the back-and-forth over what an
> “annotation” is and how the real world is evinced in BIBFRAME:
>
>
>
> *Is the BIBFRAME thingy* a surrogate for the resource?*
>
>
>
> In libraries and archives, we discuss descriptions of things as being
> surrogates for the things themselves.  Does that concept help here?
>
>
>
> Cheers!
>
>
>
> Kate
>
>
>
> PS:
>
> *thingy = “record” or “description”.    If you are not using the word
> “record” what do you call a BIBFRAME thingy?
>
>
>
>
>
> *Kate Bowers*
>
> Collections Services Archivist for Metadata, Systems, and Standards
>
> Harvard University Archives
>
> [log in to unmask] <[log in to unmask]>
>
> 617.496.2713
>
> voice: (617) 384-7787
>
> fax: (617) 495-8011
>
> web: http://nrs.harvard.edu/urn-3:hul.eresource:archives
>
> Twitter: @k8_bowers
>
>
>
>
>
> *From:* Bibliographic Framework Transition Initiative Forum [
> mailto:[log in to unmask] <[log in to unmask]>] *On Behalf
> Of *Robert Sanderson
> *Sent:* Tuesday, January 13, 2015 4:02 PM
> *To:* [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]> 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