Kevin, thanks for your comments.

The bit quoted below actually comes from Rob, but he and I did go back and forth a bit on the question of Annotation v. Authority, and where one draws the line. You mention in your other email that one way to define annotations might be to define them as "those things needing information about *who* supplied them," with the "non-Annotations" being those bits that are factual descriptions (or transcriptions) of the thing itself. I'm sure there will be grey areas, but I wonder how well this parallels the RDA division between Description and Access? If it does, the authority-controlled headings could be seen, at least structurally, as annotations because they do require additional information about the source of the data. (Which we carry in various forms in the MARC record today, in Leader codes, indicators, and $2 subfields, plus the unfortunately inadequate 040.)  Thus an LC subject heading could be an annotation that uses content from LCSH*, and was assigned by (say) Harvard. A Dewey number would have a Dewey identifier**, which includes the edition of Dewey, and was assigned by (say) San Francisco Public Library.

* http://id.loc.gov/authorities/subjects/sh85038796
* http://library.harvard.edu/

** http://dewey.info/class/636.7/e23/2012-10-24/about.en
** http://sfpl.org/

(In OA terms, I think these pairs would be oa:hasBody and oa:annotatedBy, respectively.)

This parallels pretty much what we do today in some MARC fields with indicators and $2, except that for the *who* we only know who has initially created the record, and then all of the libraries that have made modifications (but not which fields they modified).

Here it would be good to hear from some catalogers who have made the mental transition from AACR(2) to RDA: is there a relatively clear division between Description and Access such at all/most Access = authority controlled "stuff"? Can we say that BIBFRAME Work + Instance = Description, and everything else is supplied information about the bibliographic "thing"? That would give us at least a conceptual criterion to use.

Even if there isn't a bright line distinction between Description and Access (no surprise), would this at least be a good starting point for further discussion?

(Note: there are lots of complications, like everything that goes into 5XX fields today, but before getting bogged down in that, does Kevin's principle of *who-ness* hold?)

kc



On 5/6/13 1:47 PM, Ford, Kevin wrote:
[log in to unmask]" type="cite"> 
Dear Karen,


The cataloguing type of use cases I would see as
clearly annotations:

* Reviews / Notes
* Tagging / Subject classification
* Citations

--  I just wanted to call out "Subject classification."   It's certainly not that I necessarily agree or disagree with the others, but that I recall having a short off-hand discussion about whether subject assignment and classification assignment might better be expressed as an Annotation.

This quickly gets caught up in the notion (a misunderstanding, actually) that BIBFRAME Annotations are somehow second-class resources to BIBFRAME Works and Instances (they're not).  There is an automatic recoil, with an individual expressing "Subjects are integral with the work.  They're not Annotations."  However, if one accepts the definition of a BIBFRAME Annotation as additional information where the "who" is known and valued, it's just additional description.  Applying this type of approach to subject assignment could have interesting results.  My first thought was copy-cataloging, but that is dependent on how often subjects are modified as part of the copy-cataloging process.  Nevertheless, it was important, at least with classication, in MARC to provide a subfield for "source of number," suggesting that there was, at some point, value knowing *who* assigned the classification number.  The idea of "who" *could* be extended to subjects as Annotations, where it might be e
 qually in
teresting to know that LC or NLM or Harvard or some other institution assigned specific headings (one could imagine the NLM ones would have a medical bent, and not just because they probably come from MeSH, and therefore have additional value because of that fact).

I'm certainly not saying that I wholeheartedly endorse this approach, but I found it interesting that I brought this up at one point in the past and here it is quite independently presented again.  

Is what I describe the same as what you were thinking?

Yours,
Kevin




-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum
[mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: Sunday, May 05, 2013 11:02 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Annotations (Was: Documents and improvements)

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/j
ournal/11042
[4] http://bibframe.org/contribute/

--
Karen Coyle
[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] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet