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:
[log in to unmask]" type="cite">

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

[log in to unmask]" type="cite">

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.

[log in to unmask]" type="cite">
Perhaps I'm missing the point? Have you looked at the Open Annotation work, or just the Bibframe document? 
The specification: http://www.openannotation.org/spec/core/ 
And our recent (yesterday!) paper at Web Science 2013: http://arxiv.org/abs/1304.6709

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

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.

[log in to unmask]" type="cite">


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: http://www.w3.org/community/openannotation/wiki/Textual_Bodies
The distilled rationale in the specification: http://openannotation.org/spec/core/core.html#BodyEmbed

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.


[log in to unmask]" type="cite">

* 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:
http://openannotation.org/spec/core/core.html#Motivations
http://openannotation.org/spec/core/appendices.html#ExtendingMotivations

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.

[log in to unmask]" type="cite">

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

[log in to unmask]" type="cite">

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


[log in to unmask]" type="cite">


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

kc

[1] http://listserv.loc.gov/cgi-bin/wa?A2=ind1305&L=bibframe&T=0&P=751
[2] http://lists.w3.org/Archives/Public/public-openannotation/

[log in to unmask]" type="cite">

Rob, Paolo and Herbert



On Sat, May 4, 2013 at 5:27 AM, Young,Jeff (OR) <[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]> 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]> 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 bibframe.org 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:
>
>                 http://bibframe.org/documentation/annotations
>
> Then we hope to get discussion papers on BIBFRAME Authorities, Relationships, Schema.org, 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 http://bibframe.org/.  In the last couple of months, we have made the following enhancements to the BIBFRAME website:
>
>  
>
> -  Regularly updated to the vocabulary: http://bibframe.org/vocab/
>
> -  Added BIBFRAME example snippets in vocabulary section: e.g. http://bibframe.org/vocab/class-lcc
>
> -  Improved the MARC-to-BIBFRAME code: http://bibframe.org/tools/
>
> -  Added a set of Frequently Asked Questions: http://bibframe.org/faq/
>
>  
>
> 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: http://bibframe.org/contribute/.
>
>  
>
> Please read the papers that we are be putting up on bibframe.org 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]
>
> Tel. 1-202-707-5119 -- Fax 1-202-707-0115
>
> **************************
>
>  


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