LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  May 2013

BIBFRAME May 2013

Subject:

Re: Annotations (Was: Documents and improvements)

From:

"Cole, Timothy W" <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Sun, 5 May 2013 19:43:41 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (178 lines)

Thanks, Karen, for reply....
________________________________________
From: Karen Coyle [[log in to unmask]]
Sent: Sunday, May 05, 2013 12:37
To: Bibliographic Framework Transition Initiative Forum
Cc: Cole, Timothy W
Subject: Re: [BIBFRAME] Annotations (Was: Documents and improvements)

On 5/5/13 9:21 AM, Cole, Timothy W wrote:
> 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.
Hi, Tim. Thanks. I totally agree that we aren't going to have a bright
line. I am wondering about the BIBFRAME view, though. Two things in that
regard:

1) The library world, with its penchant for standards and its need for
sharing, will need to make some decisions in this area. This is where I
think that Application Profiles (or Community Profiles) could come in --
to allow different communities to describe, to themselves and others,
their view of "stuff v. annotations of stuff." I see it more as "by way
of explanation" than hard and fast rules. It should help re-use of the data.

twc: I think this is a reasonable strategy.

2) To me this points out what I see as a flaw in current library
practice, which I'm hoping to explain in an upcoming Library Journal
column (if I can make sense of what I am thinking): that libraries stop
abruptly at metadata and do not go on to include actual "stuff" as part
of their mission.

twc: strong agreement on this point, for me at least.

 I'm not talking about preserving and archiving here --
I mean *use*. The OA model is a kind of use. Visualization of data
(stats, etc.) is another kind of use. With the famed four user tasks of
FRBR, libraries wash their hands of the information world at "Obtain".
We operate in a meta-verse apart from any information resources that are
not our own metadata about our resources. This, in a sense, is the crux
of the annotation problem for libraries -- we only recognize a very
narrow view of annotation because we have such a narrow view of
resources. (Admittedly, off-line resources must still be represented as
"elsewhere" beyond the metadata, but honestly, we should be doing more
with online stuff.)

twc: Agreed. And just to be clear (which I perhaps wasn't in my earlier post), I am not trying to denigrate the value of distinguishing (for example) between Tim Cole the person and Tim Cole's Home Page, nor otherwise start a big discussion as to what you get when you de-reference URIs (if it's an HTTP URI for an annotation, the Open Annotation model says you get back "a representation of the Annotation ... in an appropriate graph serialization format."). I only wanted to suggest that generically annotations can have a lot in common with other sub-classes of resources, e.g., they may contain useful information, may themselves be targets of annotation, etc. -- which among other things says (for example) that metadata can be annotated as well as full text and to the extent that annotations of full-text are treated as a form of metadata for that full-text, these annotations-as-metadata can still usefully be the target of subsequent annotation, and so on. A broad understanding of metadata. In other words, libraries need to do a better job recognizing that annotations (and metadata generally) are content too.

All in all, for me this has been a very productive discussion, and I
thank you all. To me it goes to the heart of the library's distance from
the modern world of information.

Or maybe I'm just particularly susceptible to idle brain waves this
Sunday morning.

twc: For me it's Sunday AND I've been travelling, so apologies in advance if not making sense.

kc


> 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

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager