LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  May 2013

BIBFRAME May 2013

Subject:

Re: Annotations (Was: Documents and improvements)

From:

"Ford, Kevin" <[log in to unmask]>

Reply-To:

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

Date:

Mon, 6 May 2013 16:47:29 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (162 lines)

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 equally interesting 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

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

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