annotating scholarly resources

Annotating Scholarly Resources: An Update from OAC Robert Sanderson, Herbert Van de Sompel, Tim Cole, Jane Hunter

1

[email protected]@[email protected]@gmail.comTimColet‐[email protected]@itee.uq.edu.au

AnUpdatefromtheOpenAnnotaHonCollaboraHon

h"p://www.openannota-on.org/

ThisresearchwasfundedbytheAndrewW.MellonFoundaHon.Acknowledgements:AnnaGerber,TomHabing,BernhardHaslhofer,RayLarson,CliffLynch,

MichaelNelson,DougReside

Annotating Scholarly Resources


2

Overview

•  Introduction to the Open Annotation Collaboration

•  OAC Data Model •  OAC Transfer Model

•  Phase 2 Work in 2011


3

Open Annotation Collaboration

•  Project Partners:

•  Los Alamos National Laboratory •  University of Illinois at Urbana-Champaign •  University of Queensland •  University of Maryland •  George Mason University

•  Funding: Andrew W. Mellon Foundation

•  Discussion Group:

http://groups.google.com/group/oac-discuss


4

Current Scholarly Annotation

•  Annotations stuck in silos: •  Only consumable by client that created it •  Many clients offline/single user only •  Annotations not shareable beyond original environment:

can not create cross system services based on (enriched & merged) annotations

•  Online Annotations are Repository-centric, not Web-centric; •  Identification in terms of local identifiers, not global URIs •  Annotations stored in repository along with annotated content •  Need to rethink in terms of the Web


5

Interoperability via OAC

•  Focus on interoperability for annotations in order to allow sharing of annotations across: •  Annotation clients •  Content collections •  Services that leverage annotations

•  Interoperability is at the data model level, not protocol level

•  Focus on annotation for scholarly purposes. But desire to make the OAC framework more broadly usable. •  In order to gain adoption, we need tools, communities, integration

of scholarly communication with other areas of discourse.


6

OAC Data Model

•  Attempts to be comprehensive •  Research into existing applications •  Real world use cases •  Validated and refined via experiments

•  Changes for latest version from community feedback: •  Identifiers for resource segments to enable use in RDF •  Annotation is a document

•  Your continued feedback is very welcome!


7

Basic Model

•  The basic model has three resources: •  Annotation (an RDF document)

•  Default: RDF/XML but others possible •  Body (the content of the annotation, in any format) •  Target (the resource the body is about, in any format)


8

Basic Model Example


9

Additional Relationships and Properties

•  Any of the resources can have additional information attached

•  Links can be added to further clarify relationships


10

Additional Relationships and Properties Example


11

Annotation Types

•  The type of the Annotation can be made more precise •  Communities can develop their own types for their requirements •  Example: Replies are Annotations on Annotations


12

Annotation Types Example


13

Inline Information

•  It is important to be able to have content contained within the Annotation document.

•  Clients may be unable to mint new URIs for every resource •  Clients may wish to transmit only a single document •  Third parties can generate new URIs even if the client cannot

•  The W3C has a Content in RDF specification for this: •  http://www.w3.org/TR/Content-in-RDF10/


14

Inline Body

•  We introduce a resource identified by a non resolvable URI, such as a UUID URN, as the Body.

•  The data is embedded within the Annotation document using the 'chars' property from the Content in RDF ontology.


15

Inline Body Example


16

Multiple Targets

•  There are many use cases for multiple targets for an Annotation: •  Comparison between two or more resources •  Making a statement that applies to multiple resources •  Making a statement about multiple parts of a resource •  …

•  The OAC Data Model allows for multiple targets by simply having more than one hasTarget relationship.


17

Multiple Targets Example


18

Segments of Resources

•  Most annotations are about part of a resource

•  Different types of segment for different media types: •  Text: paragraph, arbitrary span of words •  Image: rectangular or arbitrary shaped area •  Audio: start and end time points •  Video: both area and time •  Other: slice of a data set, volume in a 3d object, …

•  We introduce a method of constraining resources: •  Can be applied to either Body or Target resource •  Use media-specific fragment identifiers; eg XPointer for XML •  Use W3C Media Fragments for segments of image/audio/video: http://www.w3.org/TR/media-frags/ •  Introduce an approach for arbitrarily complex segments


19

Segments of Resources: Fragment URIs

•  The Fragment part of URIs allows the creation of subsidiary URIs that identify part of the main resource

•  eg: http://www.example.org/page.html#para1

•  The syntax is defined for several media types: •  X/HTML: named anchor or identified element •  XML: XPointer to the element •  PDF: page number and rectangular area within •  Plain Text: character position or line position

•  For all types of Fragment URI, the Annotation must also create a dcterms:isPartOf link to the full resource for discovery purposes


20

Segments of Resources: Media Fragments

•  Media Fragments allow anyone to create URIs that identify part of an image, audio or video resource.

•  The most common use case is for rectangular areas of images: •  http://www.example.org/image.jpg#xywh=50,100,640,480


21

Media Fragments Example


22

Complex Constraints

•  The type of description is dependent on the nature of the target resource

•  Different clients may support different types of description

•  We introduce a ConstrainedTarget resource that identifies the resource with constraints applied to it in order to fully identify the target of the Annotation

•  Constraint resource describes how target resource is being used in the context of the Annotation


23

Complex Constraints Example


24

Inline Constraints

•  We can also use inline information in the same way as for the Body resource to include the Constraint data.


25

RDF Constraints

•  The information could instead be linked to the Constraint, within the Annotation document.


26

Constrained Body

•  The Body may also be constrained in the same way as Targets


27

Web-Centric Annotation: Information Changes

Google Sidewiki Annotation on http://news.bbc.co.uk/ as of 2010-06-14


28

Web-Centric Annotation: Past Not Integrated

Archived page from: http://www.dracos.co.uk/work/bbc-news-archive/2010/03/08/07.05.html


29

Web-Centric Annotation: Desired Integration


30

Uniform Annotations

•  If a single point in time is applicable to all resources, we attach it to the Annotation using the oac:when predicate

•  This timestamp can be used to discover appropriate, archived copies of the resources


31

Varied Annotations

•  If different timestamps are required for each resource, we use oac:when from an oac:TimeConstraint.


32

Serialization of the Data Model

•  All of the nodes in the data model require URIs as identifiers

•  HTTP URIs are always preferred •  Dereferencing the URI of the Annotation should return a description, following Linked Data principles •  UUID URNs are a good alternative for clients that cannot generate their own HTTP URIs

•  Servers that find a UUID can replace it with an HTTP URI they control, and serve the information from it

•  The server must also retain the original UUID and assert that it is the same as the new HTTP URI •  This allows for deduplication, when the client's original UUID is discovered by multiple servers independently


33

Network Model: No Protocol, Just HTTP

•  The client stores the Annotation document in at least one online system

•  It is just a document / web resource •  No special protocol necessary

•  An Annotation service accesses it: •  Using regular harvesting techniques •  Upon request of a client •  By being one of the places the client sends the annotation to

•  Access control uses existing mechanisms

•  Plan to refine model in Phase 2


34

OAC Phase 2

•  Aim: Will focus on Deployment and Refinement

•  Attempt to fully engage with scholars requirements and work with early adopters to help deploy implementations

•  Use those experiences to further refine the model, as needed, to cover missing functionality

•  Approach is to execute multiple small scale experiments in conjunction with new collaborators

•  Dates: January 2011 through Spring 2012


35

Phase 2: Initial New Collaborators

•  4 pre-selected experiments to start immediately:

•  Stanford University Using Annotations to transcribe medieval manuscripts

•  AustLit Using Annotations to support collaborative scholarly editions

•  Alexander Street Press Annotation of streaming video

•  Herzog August Bibliothek & University of Illinois Annotation of digital emblem books at multiple FRBR levels


36

Phase 2: Additional Experiments RFP

•  4 further experiments to be selected from an RFP:

•  $30-45k per experiment from June '11 to May '12

•  At least one partner from OAC will play an active role in each selected experiment to ensure the value of feedback, and to assist with modeling and questions

•  Scholarly use cases that exercise the model in interesting ways will be favored. The use cases should:

•  Have existing content collection(s) •  Already be web based via persistent URIs •  Have an established scholarly audience of annotators •  Demonstrate the benefits of a Web based scholarly annotation system


37

Phase 2: Using OAC Workshop

•  OAC will host a funded workshop March 24, 25 in Chicago:

•  Aim: provide attendees with an in depth introduction to using and implementing OAC •  Up to 20 attendees will be selected based upon the submission of a 1-2 page description of a relevant use case •  At the workshop, attendees will evaluate the applicability of the OAC data model to their submitted use case •  Accommodation and up to $900 towards flights will be provided

•  Participation in the workshop IS NOT required for responding to the RFP, but is likely to be useful


38

Phase 2: Dates of Note

•  01 Dec 2010: Call for Workshop Participation issued •  17 Jan 2011: Preliminary Use Case briefs due •  07 Feb 2011: Invitations issued •  01 Mar 2011: Final Use Cases due from attendees •  24 Mar 2011: Workshop •  April 2011: RFPs due •  May 2011: Additional experiments selected •  June 2011: Beginning of Experiments •  May 2012: End of Phase 2


39

http://www.openannotation.org/

annotating scholarly resources

Documents