 |
 |
The main use case that I can think of for literal annotations is the catch-all "user tagging". Think of this in terms of the open-ended tagging that Flickr allows, where it would be impossible to characterize the nature of the tags: "My vacation" "Mary again" "Eiffel tower under the moonlight" "Yesterday" Or the highly used tags in both LibraryThing and GoodReads: "Read" [which is wonderfully ambiguous in English] "To read" These deserve to be literal strings, dangling off the edge of information space, almost useless to anyone but their creators. kc On 5/9/13 8:49 AM, Owen Stephens wrote: > From Kevin's description here it sounds like this was more about > entries like: > > <datafieldtag="856"ind1="4"ind2="1"> > <subfieldcode="3">Table of contents only</subfield> > <subfieldcode="u"> > http://www.loc.gov/catdir/toc/ecip0613/2006015506.html > </subfield> > </datafield> > <datafieldtag="856"ind1="4"ind2="2"> > <subfieldcode="3">Publisher description</subfield> > <subfieldcode="u"> > http://www.loc.gov/catdir/enhancements/fy0643/2006015506-d.html > </subfield> > </datafield> > <datafieldtag="856"ind1="4"ind2="1"> > <subfieldcode="3">Sample text</subfield> > <subfieldcode="u"> > http://www.loc.gov/catdir/enhancements/fy0666/2006015506-s.html > </subfield> > </datafield> > <datafieldtag="856"ind1="4"ind2="2"> > <subfieldcode="3">Contributor biographical information</subfield> > <subfieldcode="u"> > http://www.loc.gov/catdir/enhancements/fy0737/2006015506-b.html > </subfield> > </datafield> > > Taken from http://lccn.loc.gov/2006015506 > > Owen > > Owen Stephens > Owen Stephens Consulting > Web: http://www.ostephens.com > Email: [log in to unmask] <mailto:[log in to unmask]> > Telephone: 0121 288 6936 > > On 9 May 2013, at 16:30, Stephen Hearn <[log in to unmask] > <mailto:[log in to unmask]>> wrote: > >> On the chance that I may be voicing concerns or points of confusion >> shared by others reading this list: >> >> If by "description" we mean what in the past was called "summary" and >> recorded in 520, the reasons for not making such metadata "core" had >> more to do with expedience than any judgment about the value of the >> metadata. Everyone wants such "descriptions," but they've been >> expensive to produce in terms of cataloger time; so they generally >> weren't required. >> >> The default assumption when a 520 appeared on a record was that a >> cataloger, and by extension "the library," had composed the summary. >> Using an external source, like transcribing a publisher's description >> in a 520, was considered problematic, since these descriptions were >> often promotional and not in keeping with the library ethos of >> neutrality. A solution has been to append a source statement to such >> texts in 520 to clarify that they were not composed by the library, >> e.g., "520 $a [Publisher's description]--Publisher's description." >> >> Such a text, with its appendage, could be added as a literal in the >> body of an annotation. There would be no easy way to use the source >> data it contains, but if communicating that data to end users reading >> the text was considered sufficient, and if entering such a literal >> was more expedient than assigning URLs to objects and entities in >> every case, then that might be the preferred solution. When the >> summary is already available as a URL-specified object, using that >> rather than a literal could be preferred; but my guess is that won't >> always be the case. >> >> The argument for allowing literals may have to do mainly with the >> practicalities of enabling BibFrame data creation by a widely >> dispersed and variously equipped population of libraries and other >> agencies and not with preferred data management practices. >> >> Stephen >> >> >> >> >> On Thu, May 9, 2013 at 3:42 AM, Owen Stephens <[log in to unmask] >> <mailto:[log in to unmask]>> wrote: >> >> Thanks Kevin >> > Very brief history: Annotation was proposed for the BIBFRAME >> model, at which point we started evaluating the idea along with >> the model in general. We get a lot of extra material with bib >> records, such as publisher descriptions, contributor bios, tables >> of contents, etc. These are often recorded in the 856, and we've >> been heavily evaluating BIBFRAME via our MARC records. What you >> are seeing is a very, very early attempt to rationalize what is >> commonly found in the 856 (at least our 856s). And you are also >> seeing, with these entries in the vocabulary, the outcome of a >> first cut to get things moving versus a hardened decision. As >> we've said before, it's a draft and things will change. >> (Regardless of the origin - MARC 856 - these extras are valuable >> additions to our records with a number of potential uses that we >> want to leverage in a future bibliographic ecosystem.) >> > >> > One the one hand, I completely understand (and can agree with) >> your assessment of bf:PublisherDescription; I've had the same >> thought before. It might be better simply called Description >> without reference to the source. Not all descriptions are the >> ones created by publishers. ContributorBio's definition could >> likely use some attention to make clear the distinction what type >> of biographical information. >> > >> > On the other hand, and something to bear in mind, is the "who" >> being talked about with respect to the Annotation is the agent >> responsible for creating the Annotation, which is not necessarily >> the same as the source of the Description. Not only is this an >> important distinction, but I can suddenly appreciate how this >> could lead to some confusion and I've taken note to tread >> carefully (and review earlier statements). The consumer must >> consider his/her "trust" in the annotator and, separately, >> his/her "trust" in the content creator (also, cue a few >> over-the-top and off-topic emails about the notion of "trust"). >> So, the Description Annotation may be asserted by LC (we created >> the Annotation), but that's not to say we created/authored the >> description itself. The same could be applied to SampleText and >> Tables of Contents. The Annotation is a way for us to publicize >> (if we want to) that we have SampleText (often specially >> formatted) or Tables of Contents, which have traditionally been >> treated as "add-ons" (for the lack of a better characterization) >> to the bibliographic record. These extras can assist a patron >> evaluating a potential resource (and, if indexed, can help with >> search), but are they "core" to the description? >> >> I appreciate the explanation around the "who" being talked about >> in respect to the Annotation - I think I'd misapprehended this - >> although it does start to create some confusion in my mind. If >> the provenance of the 'PublisherDescription' or 'TableofContents' >> is 'the library' - then this seems not to differ to the rest of >> the bibframe data. To take the example of Description vs >> PublisherDescription - I can easily see many parties wishing to >> assert a Description of a book - and I'm going to care who >> asserted the description. I'm unconvinced that lots of parties >> want to make the statement 'this is the publisher description of >> the book', and if they do then the question of 'who' is making >> the statement is less important (it isn't unimportant - but that >> goes for the provenance of any of the statements in bibframe). >> >> I'm uncomfortable with the idea that the Annotations are some how >> not 'core' to the description - I think this is at the root of >> the feeling mentioned previously that those things classed as >> Annotations in Bibframe are somehow second class citizens. If we >> do need to indicate core/non-core properties (which I don't >> really believe) then I think it would be better to make this some >> kind of explicit encoding, not 'implied by nature of being an >> annotation' >> >> > >> > In the end, this is really about exploring the extensibility of >> the model and the empowerment of actors outside the traditional >> bibliographic universe. For example, a service could set itself >> up as a clearinghouse, quite independent of libraries or >> publishers, for this type of information. Those clearinghouses >> would be the creators of those Annotations, even though they may >> providing access to tables of contents or sample text (or >> something else we've not yet thought of but which would >> nevertheless be a positive addition that would help our users). >> > >> > Further thoughts? >> > >> > >> > As for this: >> > >> >> I think I'm willing to accept that if they fulfil any of >> >> the criteria above (provenance is key, or 1,2,3 listed) then >> there is a >> >> justification to use an 'annotation' approach. >> > >> > I ask that BIBFRAME Annotation be evaluated on its definition >> and use cases (while acknowledging there may be overlap) versus >> the Open Annotation requirements, to which those numbers refer. >> >> Of course this is reasonable - but by subclassing oa:annotation >> and calling the approach 'annotation' I think some consideration >> of whether the bibframe use of annotation is in line with OA is >> being invited >> >> > >> > >> > Yours, >> > Kevin >> > >> > >> > >> > >> >> From: Bibliographic Framework Transition Initiative Forum >> >> [mailto:[log in to unmask] >> <mailto:[log in to unmask]>] On Behalf Of Owen Stephens >> >> Sent: Tuesday, May 07, 2013 10:29 AM >> >> To: [log in to unmask] <mailto:[log in to unmask]> >> >> Subject: Re: [BIBFRAME] BIBFRAME annotation >> >> >> >> Thanks Kevin for this attempt - I, at least, found it helpful >> in terms >> >> of thinking about how BIBFRAME uses 'annotations'. >> >> >> >> There is clearly a lot of 'grey area' in terms of what might be >> >> regarded as an annotation and what not. While acknowledging the >> >> criticism others have made that dealing in 'facts' is >> problematic, I >> >> think I understand the idea that there are things that we >> might easily >> >> get consensus on and those that we might not, or have valid >> multiple >> >> views on - but this is a spectrum. >> >> >> >> In this context it makes sense that Annotations are used when >> it is >> >> important to the provenance (especially the 'who') of a >> statement. The >> >> issue of Provenance is mentioned by Rob Sanderson as part of the >> >> rationale for developing additional vocabulary/ontology for >> the Open >> >> Annotation work in one of his recent emails. The other work on >> >> Provenance for triples has also been mentioned, but clearly >> the current >> >> situation is that OA creates a clear mechanism for this) >> >> >> >> The other examples of requirements from the Open Annotation >> work given >> >> by Rob were (numbering assigned by me here): >> >> >> >> 1) A highlighted span of text. There is an obvious target >> segment of a >> >> resource (the object), but there is no body/comment (the >> subject). As >> >> a triple must have a subject, this could not be expressed. A >> second >> >> example of this would be a bookmark where the body is also >> implicit. >> >> >> >> 2) An annotation that refers to multiple segments of a resource, >> >> multiple resources or multiple segments of multiple resources. >> In this >> >> case there would be multiple objects, which is also not >> possible to be >> >> expressed in RDF. >> >> >> >> 3) Where there are, equivalently, multiple comments, such as a >> comment >> >> in English and the same comment in French and the user agent >> should >> >> determine which is more appropriate to show to the user. >> >> >> >> While not an expert, (1) and (2) seem clear to me. I'm less >> clear why >> >> (3) can't be handled as a language tag - although I would see an >> >> argument that a translation is in itself an annotation of a >> kind :) >> >> >> >> I don't see anything in Bibframe equivalent to (1) - all bibframe >> >> annotations are intended to point at a resource, not a >> fragment as far >> >> as I can see? >> >> I don't see anything in Bibframe equivalent to (2) - all bibframe >> >> annotations are intended to point at a single resource, not >> multiple >> >> resources as far as I can see? >> >> I think (3) could apply to Bibframe - specifically in terms of >> >> bf:coverArt >> >> >> >> Having thought this through for me the first question is >> whether all >> >> Bibframe 'annotations' as currently proposed should be >> expressed as >> >> annotations. I think I'm willing to accept that if they fulfil >> any of >> >> the criteria above (provenance is key, or 1,2,3 listed) then >> there is a >> >> justification to use an 'annotation' approach. >> >> >> >> Out of the annotation classes given >> >> in http://bibframe.org/documentation/annotations/ the ones >> that strike >> >> me as falling into my interpretation of the criteria for >> 'annotations' >> >> are: >> >> >> >> bf:Review (provenance is key) >> >> bf:CoverArt (assuming this is an image of the cover - equivalence >> >> between different images of the cover but all ultimately >> making the >> >> same assertion of 'it looks like this') >> >> >> >> The others seem less clear to me: >> >> >> >> bf:ContributorBio - maybe if provenance is key, although it >> may depend >> >> on the type of biographical information being asserted - feels >> like it >> >> needs breaking down further bf:TableofContents - is this >> debated? Or >> >> likely to need multiple equivalent assertions? Feels like this >> is just >> >> a straightforward property of the work bf:SampleText - while I >> can see >> >> that there could be many examples of 'sampletext' for a single >> item, it >> >> doesn't seem likely we care 'who' made the claim it was sample >> text? >> >> Feels like a different kind of relationship to an annotation >> >> bf:PublisherDescription - this feels wrong in that why not have >> >> bf:Description, with the annotation asserting it was created >> by the >> >> 'publisher'? A 'description' seems squarely in 'annotation' >> territory, >> >> while a specific description assigned to a specific body feels >> like it >> >> could be handled without resorting to annotation >> >> >> >> Anyway - I guess my first question (I have a second for a separate >> >> email!) is - for each case where annotation is being used at >> the moment >> >> in BIBFRAME, does it really make sense, and if so, why? >> >> >> >> Owen >> >> >> >> >> >> Owen Stephens >> >> Owen Stephens Consulting >> >> Web: http://www.ostephens.com <http://www.ostephens.com/> >> >> Email: [log in to unmask] <mailto:[log in to unmask]> >> >> Telephone: 0121 288 6936 >> >> >> >> On 6 May 2013, at 21:07, "Ford, Kevin" <[log in to unmask] >> <mailto:[log in to unmask]>> wrote: >> >> >> >> >> >> Dear Karen, all, >> >> >> >> In reading your email (the below and others) as well as one or two >> >> emails from other individuals, it became clear that we missed the >> >> forest for the trees when it comes to basic definition. So, I >> wanted >> >> to offer up an answer to the basic question "What is a BIBFRAME >> >> Annotation?" >> >> >> >> I make no claims to have addressed all of the questions you >> raise, but >> >> I wanted to start with the basics before moving on to more >> specific >> >> details, such as whether BIBFRAME Annotations are >> end-user-oriented or >> >> cataloger-oriented, which is a question you asked in a >> separate email I >> >> believe. Naturally, if this spawns additional questions, >> please ask. >> >> >> >> -------- >> >> >> >> What is a BIBFRAME Annotation? >> >> >> >> A BIBFRAME Annotation is a resource that enhances our >> knowledge about >> >> the resource it annotates (the target resource). A BIBFRAME >> Annotation >> >> manages this in one of two ways. One way is for the BIBFRAME >> >> Annotation to facilitate an association between two resources >> by means >> >> of relationships. The resource being annotated is the target >> of the >> >> annotation while the resource that otherwise enhances our >> knowledge of >> >> the target resource is the body, or payload, of the >> annotation. The >> >> BIBFRAME Annotation, in this case, serves to say, "Resource A >> annotates >> >> Resource B, the target resource." The other way is for the >> BIBFRAME >> >> Annotation to be itself the carrier of additional information >> about the >> >> target resource. In this alternative, the BIBFRAME Annotation >> does not >> >> function as a lightweight abstraction layer bridging two >> resources, but >> >> an end resource that further enhances our knowledge about the >> target >> >> resource. As a matter of focus, a BIBFRAME Annotation generally >> >> refines our understanding of the target resource as a whole >> versus any >> >> one particular aspect or segment of the target resource. >> >> >> >> Another distinguishing characteristic about a BIBFRAME >> Annotation, as >> >> distinct from a BIBFRAME Work or BIBFRAME Instance, is that *who* >> >> asserted the Annotation is of paramount importance. The *who* >> being >> >> the agent stating, "This annotates that." The importance may >> range >> >> from simply wanting to know, for the sake of completeness, the >> source >> >> of the added information to needing to make a value judgment >> predicated >> >> on the identity of that source. The latter is particularly >> meaningful >> >> when the additional information may be subjective in nature. >> Reviews >> >> and ratings fall squarely into the realm of subjectivity, >> where knowing >> >> *who* is asserting the value of the review (not to mention the >> identity >> >> of the reviewer) may directly inform how the Annotation is >> treated. >> >> >> >> Another way to define a BIBFRAME Annotation in this regard is by >> >> contrast to other BIBFRAME resources. In the BIBFRAME >> universe, most >> >> of the "facts" about BIBFRAME Works, Instances, and >> Authorities are >> >> immutable, and they will likely be of interest to most users. >> Creators, >> >> producers, authors, editors, places of publication, >> publication dates, >> >> publishers, manufacturers, titles, and much more, do not >> change per >> >> individual resource. The novel /The Heart of Midlothian/ by >> Sir Walter >> >> Scott will always be titled "The Heart of Midlothian" and be >> by Sir >> >> Walter Scott. Likewise, the instance published in 1878 in New >> York by >> >> G. Munro cannot shake those facts in just the same way the >> instance >> >> published in 1885 by J.W. Lovell and company (also in New >> York) cannot >> >> escape from those facts. These are unquestionably objective >> "facts" >> >> about those resources. However, reviews of the Work will be >> subjective >> >> and come from a myriad of sources, some of which may be more >> trusted >> >> than others or may be more suitable to some audiences than others. >> >> >> >> Using the BIBFRAME Annotation model for game ratings provides >> another >> >> example. The Entertainment Software Rating Board (ESRB) assigns >> >> ratings to games based on content and age. Australian >> Classification >> >> Board does this for the Australian market. The Computer >> Entertainment >> >> Rating Organization (CERO) is the Japanese equivalent of ESRB. >> The >> >> South Koreans, Germans, Europeans, and many more groups have >> their own >> >> rating systems. In the United States, Common Sense Media is an >> >> alternative rating system that places special emphasis on age >> >> appropriateness. Rating systems abound and, despite >> similarities, each >> >> will be distinctive to their markets and audiences. Not only >> do the >> >> systems, by their nature, proffer subjective evaluations of media >> >> content, their value is only fully realized when we know *who* has >> >> assigned a particular game rating. The BIBFRAME Annotation model >> >> provides a flexible way to enhance the description of Works and >> >> Instances while enabling a scenario that maintains a certain >> separation >> >> between objective "facts" and subjective ones. >> >> >> >> The valuable information added by the BIBFRAME Annotation is, >> >> objectively, no less (or more) important than the information >> >> associated directly with a BIBFRAME Work, Instance, or >> Authority. It >> >> is just that the information conveyed by means of a BIBFRAME >> Annotation >> >> is in enriched by knowing *who* asserted the BIBFRAME >> Annotation. As a >> >> practical matter, the *who* in this model can become a filter, >> allowing >> >> consumers (libraries certainly, but potentially also patrons) >> to select >> >> annotations based on who asserted the annotation. >> >> >> >> >> >> --------- >> >> >> >> I should add that we believe the BIBFRAME Annotation model to be a >> >> positive development that will allow for a fair amount of >> flexibility >> >> in the future for libraries, and other implementers, to >> augment their >> >> data how they deem most appropriate while leaving the >> information that >> >> remains constant between descriptions untouched. >> >> >> >> We still continue to explore the possibilities and potential >> of the >> >> BIBFRAME Annotations within the BIBFRAME model as a whole, so we >> >> appreciate the additional eyes and questions - it is about >> identifying >> >> and enabling our use cases. >> >> >> >> Warmly, >> >> Kevin >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: Bibliographic Framework Transition Initiative Forum >> >> [mailto:[log in to unmask] >> <mailto:[log in to unmask]>] On Behalf Of Karen Coyle >> >> Sent: Friday, May 03, 2013 3:35 PM >> >> To: [log in to unmask] <mailto:[log in to unmask]> >> >> Subject: [BIBFRAME] BIBFRAME annotation >> >> >> >> I've had a terrible time trying to understand Open Annotation >> (why is >> >> this not just an RDF graph showing a relationship between >> things? Why >> >> does it get its own formal definition?), and now I'm looking at >> >> BIBFRAME annotation, pretty much guaranteeing even greater >> confusion on >> >> my part. >> >> >> >> BIBFRAME annotation is described as: >> >> The parties and objects involved in a BIBFRAME Annotation are: >> >> . The Target of the Annotation: A BIBFRAME Work, Instance, or >> Authority. >> >> The book, in part 1 of the illustration below. >> >> . The Annotation Body, which is the payload of the Annotation. >> The book >> >> review below. >> >> . An author, artist, reviewer, etc. who writes the Annotation >> Body. >> >> (This role is not represented formally in the Annotation >> model, but is >> >> mentioned here to clearly distinguish it from the Annotator.) The >> >> Reviewer below. >> >> . The Annotator, who asserts the Annotation. (The Annotator is not >> >> necessarily the same party as the author, etc. who wrote the >> >> Annotation.) The Annotator in part 2 of the illustration. >> >> . The Annotation itself , which points to the Body, Target, and >> >> Annotator. The Annotation, in part 2 of the illustration. [1 >> - section >> >> 2.2] >> >> ***** >> >> From this description I conclude that "Annotation" is a special >> >> instance of "node" -- a node with some semantics and a limited >> set of >> >> properties: links to a particular set of things. I'm still totally >> >> unclear why this is a special case in RDF, since things and >> links to >> >> things are inherent in the model. >> >> What BIBFRAME seems to be doing is using Annotation to mean >> "optional >> >> information." I conclude this from section 2.1 of the BIBFRAME >> >> annotation document [1 - section 2.1]: >> >> What is a BIBFRAME Annotation? >> >> >> >> For purposes of this model, a BIBFRAME Work, Instance, or >> Authority is >> >> an abstract resource. Different institutions may have >> different views >> >> of any given BIBFRAME Work, Instance, or Authority. For >> example, for a >> >> given BIBFRAME Work, InstitutionA and InstitutionB may each >> have a view >> >> of the Work, bf:Work A and bf:Work B. >> >> >> >> Certain information is integral to a Work - title and author, for >> >> example - and might be reasonably expected to be reflected in both >> >> views. Other information might be part of one view but not the >> other - >> >> information asserted (possibly by a third party) about the >> Work, which >> >> Institution A chooses to integrate into its view but Institution B >> >> chooses not to (or vice versa). >> >> >> >> A BIBFRAME Annotation is an assertion, by any party, about a >> BIBFRAME >> >> resource (Work, Instance, or Authority) that any institution >> holding a >> >> view of that resource may choose to integrate into its view, >> or choose >> >> not to. >> >> ********** >> >> There seem to be two things going on here. One is that >> different users >> >> of BIBFRAME will make different choices about what is >> "integral" to >> >> Work, Instance and Authority. >> >> The other thing is that there are *optional* bits of >> information that >> >> can be encoded as Annotations, and these can be ignored by >> anyone not >> >> interested in making use of them. Unfortunately, defining some >> elements >> >> as "unessential" means that others must be defined as "essential." >> >> This means that one person's "integral bit" with be another >> person's >> >> Annotation. Thus having annotations doesn't mean simply that >> you can >> >> ignore all Annotations, nor does it mean that you do not need >> to make >> >> choices among the "integral bits" that come from other >> sources. In this >> >> sense, Annotation doesn't appear to me to solve the problem of >> >> differences in cataloging. >> >> I *could* understand (although not necessarily favor) a regime >> in which >> >> there is a defined core (oh, yes, that word again) and >> everything else >> >> is an annotation. That is, everything else is optional. But the >> >> definition of Annotation here does not seem to make this >> separation. >> >> Another possibility for Annotation would be to define it as being >> >> "third-party information" -- anything not provided by the >> cataloger and >> >> not provided for in the cataloging rules. I'm not saying this >> would be >> >> a good idea, but it would be a clear separation between >> Annotation and >> >> not-Annotation. >> >> If there isn't some clear separation, then I don't see a great >> >> advantage over letting metadata users select elements based on >> data >> >> elements and provenance. >> >> What have I missed? >> >> kc >> >> [1] http://bibframe.org/documentation/annotations >> >> >> >> >> >> -- >> >> Karen Coyle >> >> [log in to unmask] <mailto:[log in to unmask]> http://kcoyle.net >> <http://kcoyle.net/> >> >> ph: 1-510-540-7596 <tel:1-510-540-7596> >> >> m: 1-510-435-8234 <tel:1-510-435-8234> >> >> skype: kcoylenet >> >> >> >> >> -- >> Stephen Hearn, Metadata Strategist >> Technical Services, University Libraries >> University of Minnesota >> 160 Wilson Library >> 309 19th Avenue South >> Minneapolis, MN 55455 >> Ph: 612-625-2328 >> Fx: 612-625-3428 > -- Karen Coyle [log in to unmask] http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet