Karen-

I empathize with your text, "I'm still having a hard time with the dividing line between stuff and annotations of stuff."

4 years ago at the outset of the Open Annotation Collaboration, I started out thinking that there was need for bright (or at least a fuzzy-bright) line there. However, I'm not sure now that there is. Being able to work with annotations sometimes as annotations of stuff and sometimes as stuff in their own right is proving a very powerful approach in practice. The evolution of the Open Annotation data model has been heavily influenced by experimentation, including some experimentation at Illinois (and elsewhere) with annotation of library resources (including authorities) and bibliographic information derived from MARC and from other sources. I've been struck how not useful maintaining an unequivocal distinction between annotations of stuff and stuff turns out to be in practice. A bit like the question in physics about whether light is a wave or a particle. It depends.

I also should say that our experimental experience over the last few years has heavily influenced a number of decisions intrinsic to the current Open Annotation data model, including the decisions about not including a 'hasLiteralBody' predicate and not trying to express the motivation of an annotation through sub-classing (myself and other librarians here at Illinois were on the other side of this issue for quite a while, but came around in light of our own experimentation showing that this just did not work well in practice). At Illinois we're now moving forward this summer on a brand new project within the HathTrust Research Center that will make extensive use of annotations conforming to the Open Annotation model, both in the curation of the bibliographic records and authorities and is the curation of the full text. We'll learn more, I'm sure, but it's definitely the right way for us to be going right now.

While I take your earlier point that BIBFRAME's is coming at annotation from its own unique perspective, I do think there is overlap with the use cases encompassed by Open Annotation, and I anticipate that some of the experimentation and testing done leading up to the Open Annotation data model might resonate with some of the BIBFRAME annotation use cases (though of course I understand that in other instances it might not).

Thanks,

Tim Cole
University of Illinois at UC.


________________________________________
From: Bibliographic Framework Transition Initiative Forum [[log in to unmask]] on behalf of Karen Coyle [[log in to unmask]]
Sent: Sunday, May 05, 2013 10:26
To: [log in to unmask]
Subject: Re: [BIBFRAME] Annotations (Was: Documents and improvements)

Jeff, I'm thinking about the part of FRAD that is outside of the main box (which I think may be handled by SKOS). There are some structures that modify (or, annotate) the authority data:

First, there is a "box" with:
 - name
 - identifier

Both of these are SKOS-able, I believe.

That "box" itself is modified with:
  - Access point
  -- Rules (for access point)
  --- Agency (that applied the rules)

It is this last part that looks OA-ish to me. This goes beyond what you have in VIAF, which contains an identifier for the original source, but doesn't separate access points from identities (as far as I can tell), and doesn't include rules. The Agency covered by the source URI is implied, but if you have something like NACO you may want the actual agency that made the decision (040 $a or something like that).

kc



On 5/5/13 8:05 AM, Young,Jeff (OR) wrote:
Or SKOS for that matter...

Sent from my iPad

On May 5, 2013, at 11:03 AM, "Karen Coyle" <[log in to unmask]<mailto:[log in to unmask]>> wrote:

Rob - thanks for your comments, and just a few more of mine. I'll try to reduce things down a bit.

First, it has occurred to me that, perhaps ironically, the "Functional Requirements for Authority Data", FRAD, [1] is very close to OA. Unfortunately, the English version isn't available online, but if you grab one of the ones whose language you can make out, all that really matters is Figure 2 (p. 7 in the French version, for example). It's not exactly the same, but I sense a similarity in the intent, especially in terms of making clear WHO is making the statement. FRAD adds one more thing, which is under which rules the statement is being made. I could imagine, therefore, BIBFRAME authorities looking much like OA if FRAD is adopted.


On 5/5/13 2:17 AM, Robert Sanderson wrote:

Agreed, however these were simply to demonstrate that annotations expressed in RDF require more than a single reified triple, to refute the claim that we're simply reinventing RDF graphs. There needs to be an ontology and defined structure.

Yes, and this is bringing up for me some work I'm doing around the Dublin Core Application Profiles [2]. I need to catch some other folks to have a discussion of this, but will get back to you if anything interesting arises.
Yes, definitely. The cataloguing type of use cases I would see as clearly annotations:

* Reviews / Notes
* Tagging / Subject classification
* Citations

Essentially, when the information is provided by a third party, then it would be good to be expressed as an Annotation such that the provenance information is maintained and is compatible with other systems that use Open Annotation.

I'm still having a hard time with the dividing line between stuff and annotations of stuff. A recent article explaining the OA concept [3] said:

 "Annotations describe resources with additional information, which is valu-
    able to other users, who are searching and browsing resource collections."

If you have "additional information" then there must be "non-additional information" -- and if you have a third party then there must be a first party (the second seems to get skipped over in that analogy). I don't think this is a generalizable question (one person's "additional"... etc.), but at least for any community like libraries some definition is going to be needed if annotations will have some operational meaning. That's what I think is not clear (yet) in the BIBFRAME document. I suspect that the division in library data will be based on provenance, but that's not how BIBFRAME defines annotation.



The point I was trying to make is that the bibframe annotation model has a property bf:annotationBodyLiteral, which has a literal as the object. The Open Annotation model explicitly does not allow this, for several important and well discussed reasons. Thus a point where the two models are not compatible.

Right. But then again, DC types doesn't include "literal" as a type. The whole typing thing is something I would need to think about more. If your only interest is literal v. URI, then the BIBFRAME choice is fine. If you have a video or sound file, that would be a URI. Something that is interesting in the OA model is that it allows you to make statements about the thing the URI points to [e.g. annotating a particular coordinate area on a map]. I hadn't thought about that, and now will have to go back to the OA document and see where that fits in. This is one of those areas where the "meta" aspect of library data has an affect. Must think more.....



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? OrI wouldn't assume that the BIBFRAME data will exist *as is* in the open world.

Then I would seriously question why RDF is being used at all.

I see this differently, perhaps because of my work on Application Profiles. I think that many communities will have an internal view of their data, and another "face" that they present to the open world. The basic structure of RDF, that is, triples, and the use of defined ontologies, is a good way to organize data whether it is open or not. In fact, there are enterprise uses of linked data. Modeling your enterprise data on RDF makes it much more likely that you will be able to extract a public view. In the Dublin Core arena we are looking at Application Profiles as a way to add the constraints that are needed within a community or enterprise that has some non-open needs, while easily allowing the derivation of an open view.


Was the choice of annotation as a model discussed on this list (and hence available in the archives) or was it simply presented fait accompli?

Rob, what you and I are doing here is the full extent of our ability to interact in the BIBFRAME process. If you look at the "Contribute" page [4] of BIBFRAME you will see that the only involvement for the community in the BIBFRAME development is discussion on this list. Discussion that, like this thread, takes place generally between list members with no direct involvement in BIBFRAME development. I would have simply replied to you individually, but I'm of the mind that a few readers on the list might find our musings interesting. In terms of having any influence over the development of BIBFRAME, I have no such conceit.

kc

[1] http://www.ifla.org/publications/functional-requirements-for-authority-data
[2] http://dublincore.org/documents/dc-dsp/
[3] http://www.springer.com/computer/information+systems+and+applications/journal/11042
[4] http://bibframe.org/contribute/

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


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