Print

Print


On 1/13/15 8:17 AM, Robert Sanderson wrote:
>
> Hi Karen,
>
> 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?

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. 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).

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.

I'm not defending this position, just describing what I see, and what 
the bibframe definition says. Moving from current library data to an 
approach that recognizes real world objects is going to take some 
adjustment, and this annotation/holdings question is just a small part 
of that.

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.

kc



>
> To me, the fuzzy line of annotation / not annotation for "comment 
> about X" and "table of contents of X" is much less important than the 
> fundamental inventory recording capabilities of the ontology.
>
> Rob
>
>
> On Thu, Jan 8, 2015 at 6:25 PM, Karen Coyle <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
>
>     Rob, has the working group polished its definition of
>     "annotation"? Having that definition in front of us might help
>     folks discuss these questions.
>
>     The BIBFRAME annotation is described this way in the BF
>     documentation[1]:
>
>         "Annotations are commomplace on the web. Comments about
>         photos, videos, and articles; reviews of restaurants and books
>         -- these are considered informally to be web Annotations. 
>
>         In a narrower context there are BIBFRAME Annotations. In
>         general, an Annotation asserts information about a resource; a
>         BIBFRAME Annotation asserts information about a BIBFRAME
>         resource."
>
>     Then we need a definition of "BIBFRAME resource", which is (from
>     same document):
>
>         "In the BIBFRAME context, the Target is a BIBFRAME resource:
>         Work, Instance, Authority, or Annotation "
>
>
>     This "narrower context" of BF annotation seems key. BF annotations
>     do not annotate the subject of the BF description (e.g. the book,
>     the sound recording, the map), but they annotate the BF entities
>     (Work, Instance, etc.).
>
>     Can you compare this to the OA definition?
>
>     Thanks,
>     kc
>
>     [1] http://bibframe.org/documentation/annotations/
>
>
>     On 1/8/15 2:45 PM, Robert Sanderson wrote:
>>
>>     Dear all,
>>
>>     In the W3C Web Annotation Working Group, Ray raised the use cases
>>     that BibFrame has for annotations.  While there has been some
>>     interesting discussion in that forum, I think it's more
>>     appropriate to discuss the finer details here, and hence this
>>     message to try and transition the deeper modeling questions to
>>     the right place.
>>
>>     bf:Annotation has 5 direct subClasses:
>>
>>     * Review
>>     -- A review of an Instance or Work
>>     * Summary
>>     -- A description of an Instance or Work
>>
>>     Reviews and Descriptions are canonical use cases for annotation,
>>     and the model is very clear -- the body of the annotation is the
>>     review/summary text, the annotation is the linking construction
>>     and the target is the Work or Instance.
>>
>>     The key point of these is that different reviews and different
>>     descriptions can all be equally valid, as they are subjective and
>>     depend on the annotator's point of view.
>>
>>     * CoverArt
>>     -- The association of cover artwork with the Instance
>>
>>     Linking resources together also seems like a reasonable usage of
>>     annotation, though the requirement for an annotation to do this,
>>     rather than simply including it in the resource's description is
>>     less clear.   It is less obvious that there's any subjectivity,
>>     but I can see that different images might be used by different
>>     institutions for the same Instance.
>>
>>     * TableOfContents
>>     -- The table of contents of an Instance or Work
>>
>>     Less obvious again, as there's likely only a single correct
>>     answer for the table of contents, and multiple institutions would
>>     be unlikely to want to have different versions of the ToC.  It
>>     seems like a very specific summary of a single part of the resource.
>>
>>     In both CoverArt and TableOfContents the identity of the
>>     resources is still clear:  the body is the artwork or transcribed
>>     table of contents, the annotation is the association, and the
>>     target is the instance or work.
>>
>>     And finally ...
>>
>>     * HeldMaterial (with HeldItem as a further subClass)
>>
>>     My position is that the current BibFrame model does not make
>>     appropriate use of Annotations in this case, and I think it would
>>     be significantly easier to understand and implement if Items were
>>     real resources or the annotation conveyed something slightly
>>     different.
>>
>>     In particular, the Annotation resource (HeldItem) has a
>>     lendingPolicy, an electronicLocator, accessConditions,
>>     retentionPolicy and so forth.  These are not the features of a
>>     link or association, they're the features of a physical object
>>     that the library holds.  A single URI cannot identify both a
>>     physical object and a conceptual association at the same time.
>>
>>     My test for conflation is always:  when was the resource
>>     created?  The annotation was not created at the same time as the
>>     physical object, therefore there must be two separate resources.
>>
>>     Option 1.  The annotation conveys only a single notion, that the
>>     agent creating the annotation owns a copy of the target resource.
>>
>>     Thus the same semantic pattern as other annotations follow:
>>     The annotation represents the notion that the agent creating the
>>     annotation owns a copy of the target resource, which is the Instance.
>>     The body might not be present at all if there's no identifier for
>>     the physical object, or could be the identifier for the physical
>>     object if there is one.
>>
>>     This is still somewhat strange -- it doesn't fit with the other
>>     uses of Annotation as above, nor is it the same model as the
>>     relationships between Instance and Work, or Work and Work.
>>
>>     Option 2.  Don't use annotations for this, and make HeldMaterial
>>     a subClass of bf:Resource, with a real relationship (isCopyOf or
>>     similar) with a range of bf:Instance.
>>
>>     Thus:
>>     _:x a bf:Work .   // Lord of the Rings
>>
>>     _:y a bf:Instance ;  // Harper Collins printing 2010
>>           bf:instanceOf _:x .
>>
>>     _:z a bf:HeldItem ; // Rob's copy of Harper Collins printing 2010
>>           bf:copyOf _:y .
>>
>>     With all the current properties that HeldItem and HeldMaterial
>>     have.  This is the option that I strongly prefer.
>>
>>     Rob
>>
>>     -- 
>>     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
>     m:+1-510-435-8234  <tel:%2B1-510-435-8234>
>     skype: kcoylenet/+1-510-984-3600  <tel:%2B1-510-984-3600>
>
>
>
>
> -- 
> 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