Print

Print


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