Robert, thank you for your answer. To begin with, I don't speak for 
BIBFRAME, not being in any way part of that development, but I would 
like to reply to some points from a library point of view. What I 
suspect that we have here are two things called "annotation" that are 
considerably different in their usage. This does not mean that they 
could not be brought together, but we should look beyond the term itself 
to the use cases.

More inline. And I apologize in advance for any liberties that I take in 
describing what I see as the library use case.

On 5/4/13 6:19 AM, Robert Sanderson wrote:
> Dear Karen, Jeff and all,
> Firstly, to describe why Open Annotation (not necessarily Bibframe's 
> annotations) are not just reinventing RDF named graphs or RDF 
> reification, there are many situations where the information is not 
> expressible as a single, reified triple.
> Consider the following structural use cases which we consider as 
> important for annotation:
> * A highlighted span of text.  There is an obvious target segment of a 
> resource (the object), but there is no body/comment (the subject).  As 
> a triple must have a subject, this could not be expressed.  A second 
> example of this would be a bookmark where the body is also implicit.
> * An annotation that refers to multiple segments of a resource, 
> multiple resources or multiple segments of multiple resources.  In 
> this case there would be multiple objects, which is also not possible 
> to be expressed in RDF.
> * Where there are, equivalently, multiple comments, such as a comment 
> in English and the same comment in French and the user agent should 
> determine which is more appropriate to show to the user.
> Then there are many additional features that require additional 
> information, including describing segments of resources that cannot be 
> described using URI fragments, such as non rectangular spatial areas, 
> arbitrary text spans or segments of representations that do not have a 
> fragment definition for the media type.  Also, styling of the 
> annotation, the state of the resource in order to derive the correct 
> representation, and provenance information for the annotation itself.

Of the above, the only one that I perceive as a library cataloging data 
use case is the multi-lingual one. I also note that one of the 
annotation types in OA is parallel to the library use case of subject 
assignment. What I see here is a difference between the annotation of 
documents, something similar to "citing" or "commenting on," and the 
addition of information to a set of descriptive metadata. It is for this 
reason that I propose that we look closer at the use cases and determine 
if we aren't making too much of the use of the term "annotation."

> Unless you're claiming that annotation does not require a model or any 
> new vocabulary/ontology? At the very least there needs to be a notion 
> of provenance of the annotation graph, and the resources involved in it.

AFAIK, provenance is on its way to becoming a generalized concept in 
RDF, therefore is not unique to OA. Provenance will be very important to 
libraries where the concept of "authoritativeness" of data is essential 
to our extensive sharing of metadata.

> Perhaps I'm missing the point? Have you looked at the Open Annotation 
> work, or just the Bibframe document?
> The specification:
> And our recent (yesterday!) paper at Web Science 2013: 

There will be many on this list who have not read the OA documentation, 
and I admit that there were parts that I just skimmed through because 
they didn't seem relevant to my interests. But there are a number of us 
who are following the W3C semantic web work as closely as we can. At the 
same time, there is much beyond BIBFRAME that is not explicit in the 
BIBFRAME documents but that is deeply embedded in library culture and 
practices, and therefore may not be obvious on a reading of the BIBFRAME 

BIBFRAME currently is greatly under-specified, so comparing the BIBFRAME 
document to the OA document probably isn't useful. Which is why I 
suggest that we compare the use cases and intention to see what overlap 
of interests exists.

> And secondly to enumerate the areas of incompatiblity:
> * bf:annotationBodyLiteral
> This pattern is not available in the Open Annotation model, after much 
> discussion.
> The wiki discussion page: 
> The distilled rationale in the specification: 
> Note that in the bibframe document, the solution we adopt is also 
> used, being the Content in RDF specification.
> Also note that this spec is less mature than the Open Annotation spec, 
> yet the Annotation model is reproduced and the content in RDF model is 
> reused.
OA uses Dublin Core types vocabulary for this. That may be a solution, 
but only if one accepts the OA structure. What we in the library world 
need to think about, IMO, is how far we want to go with typing our 
annotations, and what the trade-off is in terms of complexity.

Note that there is nothing about library data that would prevent anyone 
from applying an Open Annotation to the data. The question is, do we 
want this to be the only way to, for example, assign a subject heading 
to a Work? Or to link reviews to a bibliographic description? Library 
data has a different mechanism for linking subject headings to Works, 
called "Authorities." This was my point in the earlier email [1] about 
separating the basic elements of cataloging (resulting in bibliographic 
metadata) from user-supplied "annotations." If the latter, then OA could 
be the standard for user-supplied annotations, while library data would 
continue to use its duality of "description and access."

What you may not know is that the concept of "annotation" is far from 
accepted in library cataloging. It was introduced with BIBFRAME and my 
guess is that the vast majority of librarians do not have this concept 
in their mental tool-kit. My impression is that BIBFRAME is so far from 
"cooked" that what we see today in the documentation may not be what is 
at the end. All the more reason to have this conversation about 
annotations now while BIBFRAME is still somewhat fluid. I can tell you 
that once a standard gets accepted and implemented in the library world, 
changes become extremely costly, which is why we are struggling today 
with a 40-year-old data standard that no longer meets our needs.

> * Motivation vs SubClassing
> The Open Annotation model recommends motivations as a means of 
> expressing the rationale behind the creation of the Annotation, yet 
> the Bibframe model uses subclasses of Annotation.
> The motivation system is extensible and able to be integrated 
> post-factum across communities as it is based on the SKOS model, 
> rather than simple subclassing.
> See:

If we see BIBFRAME annotations being assigned by catalogers, then 
"motivation" isn't a terribly relevant concept. Cataloging follows 
cataloging rules and isn't "motivated" individually. However, I can see 
a need to type the annotations, and that could be through a property 
sub-type, an annotation sub-class, or using a mechanism like OA 
motivations (although not actually OA Motivations). Again, it seems 
worth thinking about the variety of annotations that libraries may use, 
and the best way to manage and extend that.

> * Inline Annotations
> These annotations do not have an explicit target, which is required in 
> Open Annotation.  It could be argued that bf:annotation is the inverse 
> property of oa:hasTarget, but that is not clear from the current document.
> Also, in RDF there is no notion of "embedded" or "records", there is a 
> single global graph that uses the open world assumption.  This 
> "inline" annotation is typical closed world thinking, where a "record" 
> is something that exists.  So to say "the Target is assumed to be the 
> resource in which it is embedded" is not meaningful.

I wouldn't assume that the BIBFRAME data will exist *as is* in the open 
world. It may (I hope) be more easily translatable to the open world, 
but libraries need a sharable data format that replaces the current 
record format. So I do think that it is appropriate to *also* think of 
BIBFRAME as a record, and that some of its "record-ness" may remain 
within a library silo because it is only relevant there. A primary use 
case for library metadata is the sharing of descriptions of published 
materials that make up the inventories of library holdings, and are key 
to the management functions of library systems (acquisitions, collection 
development, circulation). These descriptions are indeed "records" 
regardless of the technology being used to hold the metadata. The 
soon-to-be-current cataloging rules separate "description" and "access." 
To my mind, the "access" part is most interesting as linked data, while 
the "description" part functions as a bound package (c.f. ISBD as the 
data "core").

That said, librarians are having a hard time wrapping their heads around 
the open world idea of data. We've had records for a long time, even 
before they were digital. We can go back to the "unit entry" of the book 
catalogs of pre-1850 if we want to trace our basic concepts. This makes 
it harder to stand back and question our assumptions about data.

> * The Reinvention of the Model
> There's no reason to reinvent all of the terms, classes, properties 
> and relationships. The redundancy is astounding, and unnecessary. 
> Especially, as above, given the re-use of DC Terms and Content in RDF. 
>  One would expect, given the negative view from the "Reuse of 
> Ontologies" thread on this mailing list, that these would also be 
> recreated in the bf ontology.
As I say above, until we study the library use cases, what we have here 
may just be a coincidence of terminology. I believe that is the first 
step: compare use cases.

> Hope that helps,
And I hope this does, as well. Feel free to post this to the OA list. 
(The archives are open [2] but the discussion is very detailed and 
mostly does not seem relevant to the library use case, as I see it.)



> Rob, Paolo and Herbert
> On Sat, May 4, 2013 at 5:27 AM, Young,Jeff (OR) <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
>     As Karen Coyle suggested (if I skimmed her recent comments
>     correctly), what if you guys can't agree because you're both
>     merely reinventing RDF graphs?
>     Jeff
>     Sent from my iPad
>     On May 3, 2013, at 4:16 PM, "Robert Sanderson"
>     <[log in to unmask] <mailto:[log in to unmask]>> wrote:
>>     Dear Sally, Ray and all,
>>     As co-chairs and co-editors of the W3C Open Annotation Community
>>     Group, Paolo, Herbert and I would again like to invite members of
>>     the BIBFRAME group to continue the discussion of interoperable
>>     annotation on the mailing list for the W3C Community Group. There
>>     is neither a cost nor membership requirement to joining.
>>     We feel it is fair to say that the Open Annotation effort has
>>     gained significant momentum, being the 6th largest community
>>     group with many active and ongoing discussions. However there is
>>     always room for improvement, and we still believe that both
>>     BIBFRAME and Open Annotation would benefit from an open
>>     discussion of the issues that resulted in the divergence which is
>>     clear in the annotation document.
>>     It is regrettable that the BIBFRAME annotation model is neither
>>     compatible nor interoperable with the Open Annotation Data Model,
>>     especially given the significant overlap between the target
>>     communities of Open Annotation and BIBFRAME.  We are disappointed
>>     that prior efforts to engage with the BIBFRAME community
>>     regarding annotation did not yield more constructive results to
>>     this stage. We hope that our invitation to discuss issues on the
>>     W3C Community Group will be met positively as we feel we owe it
>>     to our communities to work towards convergence.
>>     Respectfully,
>>     Robert Sanderson, Paolo Ciccarese, and Herbert Van de Sompel
>>     On Fri, May 3, 2013 at 12:08 AM, McCallum, Sally <[log in to unmask]
>>     <mailto:[log in to unmask]>> wrote:
>>     >
>>     > Thanks to all for your comments and ideas over the last few
>>     months.  The small team that we have called the Early
>>     Experimenters has prepared some discussion papers on difficult
>>     topics related to the BIBFRAME model and the developing draft
>>     vocabulary.  Now we want to put these papers on
>>     <> and begin discussion on this listserv.   By
>>     preparing background and recommendation papers we hope to help
>>     focus the discussion on the issues.
>>     >
>>     >
>>     >
>>     > The issues are some of the hard ones that all of us who deal
>>     with bibliographic data run into  -- always.   We are starting
>>     with the BIBFRAME Annotations paper, which you can find here:
>>     >
>>     >
>>     >
>>     > Then we hope to get discussion papers on BIBFRAME Authorities,
>>     Relationships, <>, and Resource types
>>     out soon, followed by Holdings, Aggregates, and other issues.
>>     These were prepared by various subgroups of the Experimenter
>>     team.  We do not want to send everything at once as we would like
>>     you to have focus rather than overload.
>>     >
>>     >
>>     >
>>     > We ask that when discussing the topics, you name your listserv
>>     comment with the topic short title (indicated on the topic paper)
>>     with an extra title to bind threads, e.g., "annotations--main point".
>>     >
>>     >
>>     >
>>     > We at LC continue to work on the conversion of MARC data,
>>     which, along with RDA, is the current feeder of the current
>>     vocabulary available at  In the last couple
>>     of months, we have made the following enhancements to the
>>     BIBFRAME website:
>>     >
>>     >
>>     >
>>     > -  Regularly updated to the vocabulary:
>>     >
>>     > -  Added BIBFRAME example snippets in vocabulary section: e.g.
>>     >
>>     > -  Improved the MARC-to-BIBFRAME code:
>>     >
>>     > -  Added a set of Frequently Asked Questions:
>>     >
>>     >
>>     >
>>     > We have made every effort to update the MARC-to-BIBFRAME
>>     transformation code after modifying the vocabulary, and we plan
>>     to change and enhance the code based on feedback from the papers.
>>      You can begin using the transformation code today as a reference
>>     and starting point for your own explorations.  See the contribute
>>     page to learn more:
>>     >
>>     >
>>     >
>>     > Please read the papers that we are be putting up on
>> <> and participate in the
>>     discussion -- we are all in this together!
>>     >
>>     >
>>     >
>>     > Sally
>>     >
>>     >
>>     >
>>     > **************************
>>     >
>>     > Sally H. McCallum
>>     >
>>     > Chief, Network Development and Standards Office
>>     >
>>     > Library of Congress,  101 Independence Ave., SE
>>     >
>>     > Washington, DC 20540  USA
>>     >
>>     > [log in to unmask] <mailto:[log in to unmask]>
>>     >
>>     > Tel. 1-202-707-5119 <tel:1-202-707-5119> -- Fax 1-202-707-0115
>>     <tel:1-202-707-0115>
>>     >
>>     > **************************
>>     >
>>     >

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