Karen said:

Then there is the question of whether the target would ever be more granular
than W, I, A? For example, with cataloger notes, one might want to annotate
a particular descriptive statement within, say, Work. Perhaps it is best to
defer this question until more general ones are answered.


No, I don't think it's best to defer this discussion.  It's fairly


The Annotation model states this view of the BIBFRAME model:


"For purposes of this model, a BIBFRAME Work, Instance, or Authority is an
abstract resource. Different institutions may have different views of any
given BIBFRAME Work, Instance, or Authority. For example, for a given
BIBFRAME Work, InstitutionA and InstitutionB may each have a view of the
Work,  bf:Work A and bf:Work B."


A BIBFRAME Annotation annotates the abstract object and not its description.
There was quite a bit of debate among the contributors over this, and if
there is a fundamental objection to this, now is probably the time to raise
it.  But if this view of the BIBFRAME model holds, then no, you can't
"annotate a particular descriptive statement within, say, Work."




From: Bibliographic Framework Transition Initiative Forum
[mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: Tuesday, May 07, 2013 11:57 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] BIBFRAME annotation



One other difference that I see is the typing of the target. This may not be
a vital difference since such typing is non-mandatory (for whatever
mandatory means in the open world of linked data, but that's a whole other
question I have about the OA model). OA uses dctypes, like "text," "image,"
"sound." Even for OA I question whether these are sufficiently granular to
be useful ("image" and "sound" can be a whole plethora of actual digital
file types). 

As I read the BIBFRAME diagrams, the annotations are intended to annotate
the major "things" of the BIBFRAME world. Will it be useful to type these as
targets? And what would those types be? One possibility is that "Work"
"Instance" and "Authority" are defined as target types for BIBFRAME use.
Another, more general one is that the type is simply "graph", which is more
analogous to the OA types. 

The typing of hasBody might be the same as OA, but that's an hypothesis to
be tested.

Then there is the question of whether the target would ever be more granular
than W, I, A? For example, with cataloger notes, one might want to annotate
a particular descriptive statement within, say, Work. Perhaps it is best to
defer this question until more general ones are answered.


p.s. Except for Kevin I don't believe we have heard from anyone else
involved in the development of the BIBFRAME annotation draft. I would be
interesting to hear if any of this discussion is at all useful to their

On 5/7/13 7:48 AM, Owen Stephens wrote:

My first question about Annotations in Bibframe was about whether the
existing proposed uses of Annotation were 'valid' - or could be said to meet
some criteria as to why they were 'annotations'. 


My second is about the differences between Bibframe annotations and Open
Annotation. As bf:Annotation is declared a subclass of oa:Annotation it
seems that there is a desire to share a common conception of what an
'annotation' is.


The immediately obvious major difference between the way Bibframe
Annotations and OA is that to specify the type of annotation Bibframe uses
subclasses while OA uses the concept of 'motiviation'. I have to admit I
struggle to see why Bibframe should do this differently to OA given that
there is so much to gain through doing it in the same way. If there is
anything to say about why bibframe proposes to do this via subclassing it
would be really good to know, as the OA documentation makes it clear why
they decided to go with the 'motivation' approach, and seems
explicitly designed for scenarios such as the BIBFRAME one where a community
has some need to specify a certain type of annotation.


In a recent email Rob Sanderson also highlighted another difference which is
allowing the use of literals to carry the body of an annotation. Again the
OA case for not allowing this is documented
<> and seems to include
some use cases that seem likely to impact on the library domain - e.g.
knowing directionality of text, knowing how text is encoded. Again I think
some explanation of why Bibframe feels it is important to support the
annotationBodyLiteral would be welcome.


In Eric Miller's recent email he noted that "Ray Denenberg (the Editor for
this doc) [...] sees the compatibility and interoperability differences to
be minor to negligible,". If these two differences are the major issues
here, I tend to agree that there are not major differences - which, to be
honest, just makes me wonder all the more why they are necessary :)





On 6 May 2013, at 21:07, "Ford, Kevin" <[log in to unmask]> wrote:

Dear Karen, all,

In reading your email (the below and others) as well as one or two emails
from other individuals, it became clear that we missed the forest for the
trees when it comes to basic definition.  So, I wanted to offer up an answer
to the basic question "What is a BIBFRAME Annotation?"

I make no claims to have addressed all of the questions you raise, but I
wanted to start with the basics before moving on to more specific details,
such as whether BIBFRAME Annotations are end-user-oriented or
cataloger-oriented, which is a question you asked in a separate email I
believe.  Naturally, if this spawns additional questions, please ask.


What is a BIBFRAME Annotation?

A BIBFRAME Annotation is a resource that enhances our knowledge about the
resource it annotates (the target resource).  A BIBFRAME Annotation manages
this in one of two ways.  One way is for the BIBFRAME Annotation to
facilitate an association between two resources by means of relationships.
The resource being annotated is the target of the annotation while the
resource that otherwise enhances our knowledge of the target resource is the
body, or payload, of the annotation.  The BIBFRAME Annotation, in this case,
serves to say, "Resource A annotates Resource B, the target resource."  The
other way is for the BIBFRAME Annotation to be itself the carrier of
additional information about the target resource.  In this alternative, the
BIBFRAME Annotation does not function as a lightweight abstraction layer
bridging two resources, but an end resource that further enhances our
knowledge about the target resource.  As a matter of focus, a BIBFRAME
Annotation generally refines our understanding of the target resource as a
whole versus any one particular aspect or segment of the target resource.  

Another distinguishing characteristic about a BIBFRAME Annotation, as
distinct from a BIBFRAME Work or BIBFRAME Instance, is that *who* asserted
the Annotation is of paramount importance.  The *who* being the agent
stating, "This annotates that."  The importance may range from simply
wanting to know, for the sake of completeness, the source of the added
information to needing to make a value judgment predicated on the identity
of that source.  The latter is particularly meaningful when the additional
information may be subjective in nature.  Reviews and ratings fall squarely
into the realm of subjectivity, where knowing *who* is asserting the value
of the review (not to mention the identity of the reviewer) may directly
inform how the Annotation is treated. 

Another way to define a BIBFRAME Annotation in this regard is by contrast to
other BIBFRAME resources.  In the BIBFRAME universe, most of the "facts"
about BIBFRAME Works, Instances, and Authorities are immutable, and they
will likely be of interest to most users.  Creators, producers, authors,
editors, places of publication, publication dates, publishers,
manufacturers, titles, and much more, do not change per individual resource.
The novel /The Heart of Midlothian/ by Sir Walter Scott will always be
titled "The Heart of Midlothian" and be by Sir Walter Scott.  Likewise, the
instance published in 1878 in New York by G. Munro cannot shake those facts
in just the same way the instance published in 1885 by J.W. Lovell and
company (also in New York) cannot escape from those facts.  These are
unquestionably objective "facts" about those resources.  However, reviews of
the Work will be subjective and come from a myriad of sources, some of which
may be more trusted than others or may be more suitable to some audiences
than others.

Using the BIBFRAME Annotation model for game ratings provides another
example.  The Entertainment Software Rating Board (ESRB) assigns ratings to
games based on content and age.  Australian Classification Board does this
for the Australian market.  The Computer Entertainment Rating Organization
(CERO) is the Japanese equivalent of ESRB.  The South Koreans, Germans,
Europeans, and many more groups have their own rating systems.  In the
United States, Common Sense Media is an alternative rating system that
places special emphasis on age appropriateness.  Rating systems abound and,
despite similarities, each will be distinctive to their markets and
audiences.  Not only do the systems, by their nature, proffer subjective
evaluations of media content, their value is only fully realized when we
know *who* has assigned a particular game rating.  The BIBFRAME Annotation
model provides a flexible way to enhance the description of Works and
Instances while enabling a scenario that maintains a certain separation
between objective "facts" and subjective ones.

The valuable information added by the BIBFRAME Annotation is, objectively,
no less (or more) important than the information associated directly with a
BIBFRAME Work, Instance, or Authority.  It is just that the information
conveyed by means of a BIBFRAME Annotation is in enriched by knowing *who*
asserted the BIBFRAME Annotation.  As a practical matter, the *who* in this
model can become a filter, allowing consumers (libraries certainly, but
potentially also patrons) to select annotations based on who asserted the


I should add that we believe the BIBFRAME Annotation model to be a positive
development that will allow for a fair amount of flexibility in the future
for libraries, and other implementers, to augment their data how they deem
most appropriate while leaving the information that remains constant between
descriptions untouched.  

We still continue to explore the possibilities and potential of the BIBFRAME
Annotations within the BIBFRAME model as a whole, so we appreciate the
additional eyes and questions - it is about identifying and enabling our use


-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum
[mailto:[log in to unmask] <> ] On Behalf Of
Karen Coyle
Sent: Friday, May 03, 2013 3:35 PM
To: [log in to unmask]
Subject: [BIBFRAME] BIBFRAME annotation

I've had a terrible time trying to understand Open Annotation (why is
this not just an RDF graph showing a relationship between things? Why
does it get its own formal definition?), and now I'm looking at
BIBFRAME annotation, pretty much guaranteeing even greater confusion on
my part.

BIBFRAME annotation is described as:
The parties and objects involved in a BIBFRAME Annotation are:
. The Target of the Annotation: A BIBFRAME Work, Instance, or Authority.
The book, in part 1 of the illustration below.
. The Annotation Body, which is the payload of the Annotation. The book
review below.
. An author, artist, reviewer, etc. who writes the Annotation Body.
(This role is not represented formally in the Annotation model, but is
mentioned here to clearly distinguish it from the Annotator.) The
Reviewer below.
. The Annotator, who asserts the Annotation. (The Annotator is not
necessarily the same party as the author, etc. who wrote the
Annotation.) The Annotator in part 2 of the illustration.
. The Annotation itself , which points to the Body, Target, and
Annotator. The Annotation, in part 2 of the illustration.  [1 - section
From this description I conclude that "Annotation" is a special
instance of "node" -- a node with some semantics and a limited set of
properties: links to a particular set of things. I'm still totally
unclear why this is a special case in RDF, since things and links to
things are inherent in the model.
What BIBFRAME seems to be doing is using Annotation to mean "optional
information." I conclude this from section 2.1 of the BIBFRAME
annotation document [1 - section 2.1]:
What is a BIBFRAME Annotation?

For purposes of this model, a BIBFRAME Work, Instance, or Authority is
an abstract resource. Different institutions may have different views
of any given BIBFRAME Work, Instance, or Authority. For example, for a
given BIBFRAME Work, InstitutionA and InstitutionB may each have a view
of the Work,  bf:Work A and bf:Work B.

Certain information is integral to a Work  - title and author, for
example - and might be reasonably expected to be reflected in both
views. Other information might be part of one view but not the other -
information asserted (possibly by a third party) about the Work, which
Institution A chooses to integrate into its view but Institution B
chooses not to (or vice versa).

A BIBFRAME Annotation is an assertion, by any party, about a BIBFRAME
resource (Work, Instance, or Authority) that any institution holding a
view of that resource may choose to integrate into its view, or choose
not to.
There seem to be two things going on here. One is that different users
of BIBFRAME will make different choices about what is "integral" to
Work, Instance and Authority.
The other thing is that there are *optional* bits of information that
can be encoded as Annotations, and these can be ignored by anyone not
interested in making use of them. Unfortunately, defining some elements
as "unessential" means that others must be defined as "essential."
This means that one person's "integral bit" with be another person's
Annotation. Thus having annotations doesn't mean simply that you can
ignore all Annotations, nor does it mean that you do not need to make
choices among the "integral bits" that come from other sources. In this
sense, Annotation doesn't appear to me to solve the problem of
differences in cataloging.
I *could* understand (although not necessarily favor) a regime in which
there is a defined core (oh, yes, that word again) and everything else
is an annotation. That is, everything else is optional. But the
definition of Annotation here does not seem to make this separation.
Another possibility for Annotation would be to define it as being
"third-party information" -- anything not provided by the cataloger and
not provided for in the cataloging rules. I'm not saying this would be
a good idea, but it would be a clear separation between Annotation and
If there isn't some clear separation, then I don't see a great
advantage over letting metadata users select elements based on data
elements and provenance.
What have I missed?

Karen Coyle
[log in to unmask] <> 
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet



Karen Coyle
[log in to unmask]
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet