 Again, thank you all for coming, and thanks to Cliff for the shout-out during the opening plenary. So, I'm going to talk about the Open Annotation Collaboration Project that we're involved with at Los Alamos National Labs. First I want to talk a little bit about the collaboration and the project as a whole, but rather than bore you with tedious organisation of details, I'm going to go through the hopefully less tedious data model and protocol-less approach that we've come up with. Finally, we'll go through a demo and then a brief summary. So, the collaboration is of five funded partners, Los Alamos National Labs with Herbert and myself, the University of Illinois at Urbana-Champaign, where Tim Cole is the PI, the University of Queensland in Australia, where Jane Hunter is the PI, University of Maryland, Neil Freistat is the PI, and George Mason University. Like I said, short. The project then, we have three main aims, which are understandably high level, to facilitate a web-centric and interoperable annotation environment. So, the key emphasis here is the web-centricness of the interoperability. We demonstrate that proposed environment for scholarly use cases, and then to seed adoption by deployment of high visibility production systems. So, we have JSTOR on board for that last bullet point. Currently, we're in phase one, at the beginning of phase one even. So, we're going through the exploration of existing systems, exploration of requirements and use cases. We have an initial interoperability specification, which I'm going to go through, and we have made progress on integrating AX and Zotero, which I'm sure you're all familiar with. Many thanks to the Mallon Foundation for funding this. We have 14 months for the current phase, and we hope to proceed after that on to phases two and three. Current stressed climate to use cliff term. We have a very strong advisory board. It's practically a who's who of scholarly annotation from Maristala Agosti at the University of Padua down to John Willbrink of Science Commons. I'm sure you can see people there that you recognise. We also have a technical group. So, unlike previous open annotation initiatives type of project, we have a completely open technical list. Please, please join, or have your techie join. It's the Google Groups URI there. Current members, not exactly the same as the project members. So, we have Bruce Darkas from University of Ohio, Ed Summers from Library of Congress, Michael Nelson, Sir Thing in the Front Row, and Bernard Hasselhoffer from University of Vienna. So, interoperability then. We've gathered use cases and requirements primarily from humanity scholars, but also from scholarly literature and just looking at existing annotation systems. We're in sort of an initial design phase. This is the first part of phase one, thread one, which we're responsible for. It was discussed at a face-to-face meeting at UC Berkeley about a month and a half ago. We've had some initial feedback on the model. So, in particular, the three points as to the difficulty of defining what an annotation actually is, that the model that we've come up with is very generic and we risk absolutely every piece of scholarly work being an annotation. So, we need to sort of narrow in from our very broad reaching use cases and try and figure out exactly where we need to be. We, and by we, I don't mean the project as a whole, just myself and Herbert tend to agree, but we would very much appreciate your feedback. We have a set of 10 sort of core principles. The three basic ones, which aren't to do with the data model, are as follows. Obviously, we focus on interoperability. I think that's what we're well known for, to allow annotation sharing. There are very, very many non-interoperable annotation systems already. You just have to think of the web sticky notes websites out there to note that. There are also existing interoperability mechanisms such as Anatea, which is a W3 standard. However, they are in dire need of updating. Following on from OAIO RE, we have an interoperability approach which is based very firmly in the architecture of the web. So, we recognise that communication is increasingly online. The resources that scholars are talking about are increasingly online. We also want to maximise our chance of adoption by not being domain centric, by not saying we're going to use this particular protocol with this particular set of data. We feel that the semantic web principles and link data, which Cliff and his accustomed clarity called dispersed data during his plenary, we feel that those guidelines are extremely important. Finally, from the link data guidelines, we recognise that entities within the model must be identified by HTTP URIs. That's not a capital must, it's the first bullet point when possible. We also see that there are cases when you couldn't assign an HTTP URI as desirable as that may be. The advantages of doing so, however, are pretty drastic. You get globally unique identifiers for every entity within the model without any sort of central system overhead and their locators as well as identifiers. You can go to the URI and get back some sort of representation. So, those are the basic principles. Onto the data model then. So, this is not set in stone. The first bullet point I really want to stress. So, please provide feedback if you've got concerns, queries, questions we would love to hear them. It's also not published as a specification. We don't think it's ready for that yet. Just as guidelines and current thinking. In fact, this presentation is probably the most complete specification of the system as it stands. We've implemented it, but it's definitely a demonstrator. It's not by any means a production system yet. We're informed by previous work and expert contributions, but we strongly believe that we extend beyond them. For good reason. So, we're guided by these requirements and use cases that we've analysed. Which we feel will ensure adoption by not falling into the trap that former digital library protocols beginning with Z that I won't name fell into by adding and adding and adding features until they became completely incomprehensible. It also keeps us in touch with real users on their needs. There's no point adding stuff when no-one wants it. So, as I go through the data model, I'm going to build it up in steps, each of which will be justified with an appropriate use case. So, step one is a very basic requirement. Users must be able to create an annotation with some content about a target. If you can't do that, then you're not playing the annotation game. And we have a very, very straightforward model and baseline model in order to do that. So, we have a source of content which is the blue node, which is somehow about the target, which is the red node. We then add an annotation node, the yellow one, which represents kind of the event. So, it has a time and a creator. So, I'm going to come back to this as about property. You could imagine any triple or any set of information being captured in those nodes otherwise. So, as we have a baseline model where any resource on the web can participate in the model, that means that anything can be the content as well as the target. So, this is kind of the first distinction that we have made, the first difference that we've come to from previous models. So, here's an example where a YouTube video, the Hubble Deep Field, the most important image ever taken, is somehow about the Hubble Ultra Deep Field image, as exemplified by that file from Wikimedia Commons. Yeah, in the... note the URIs there for those. So, this means that any content can be used, doesn't have to have a particular format, doesn't have to have a particular language, it could be no language if it's an image, it could be anywhere on the web. Of course, we need to have some additional information about the annotation, such as who created it, when it was created, but also we try to instantiate that is about this, which we call a predicate following RDF. So, for example, you could say that I'm the creator of the annotation event because I'm saying that this video annotates this image. I created it on the 3rd of December, and the relationship between the content and the target is a predicate called OAC Annotates. So, the Hubble Deep Field YouTube video annotates the Hubble Deep Field image. All right, so that's the baseline model. That's from the basics from where we built. So, I know a lot of you are thinking, hang on, using a video as the content of the annotation, not many systems allow that. This is starting from a weird place. So, one thing that we bear that totally in mind, however, assigning URIs to strings of content is increasingly easy on the web today. So, for example, Twitter will assign you a URI for 140 characters. Google Docs could assign you a URI for a much longer document. So, we don't think that that's a drastic problem with the baseline. We do recognise it, however. To the point where step 2 is allowing for the case where you can't assign an HTTP URI to your content. So, our requirement then is that the model must support systems which only support a user entered string as the content of the annotation. So, here's a screenshot of a quite sophisticated annotation system called FAB4 which has signed annotations, distributed search, multiple formats and robust annotations across multiple formats and so on. However, it only allows for strings entered by the user into that interface for content. So, here's the case where we introduce a non-resolvable URI so not an HTTP URI which is called a URI. We're going to come back to this later in the protocol list, the lack of protocol part as to how this can be resolved. But as to the model, we have this node which takes the space of the content resource and we attach a property to it called OAC body. So, this is where that string would end up in the model. We also have a class called a note which is just a hint to any client receiving the annotation to say, don't bother trying to resolve that URI you're not going to get anything from it, don't try and embed it, just looking at OAC body that's your content. So, for example, we could turn that previous tweet into an annotation in this mode so we'd assign it a UUID URI we'd attach to that the string by OAC body and the target remains the same the double-deb field image. As we've worked through looking at use cases and requirements, existing systems we came to the conclusion that most if not all, but definitely most annotations are actually about a part of a resource, not the entire resource. If you've got an image it's not that common you want to talk about the entire image. Normally you'll want to say this part of the image is interesting, or you don't want to have this paragraph in the document. So a couple of examples of systems that do that I'm sure you're all familiar with Flickr, the photo sharing site you can have annotations about segments of the images, so I'm going to say it would be cool if this streetlight was the moon, but it's not. In the more sort of scholarly realm the Pliny annotation system from Kings College London also allows it on the left. So we have a very easy out for this, which is a W3 standard which is coming out called the Media Fragment URIs. This allows us to put a little bit on the end of any URI and all of a sudden it talks about in a standardized way a segment of that resource, not the whole resource. So you don't need to go mincing new URIs which are divorced from the main resource, you can just create your own little segments. For example, you'd put the hash and then X, Y, WH and then comma separated values for the X, Y dimensions in height. So using this, we can then put that URI where we'd have just normally the URI for the Hubble image. So here's another tweet, the cluster of galaxies looks very tightly packed I guess we need a 3D model to be sure. And the target is instead this box here, if you can see the mouse which would be perhaps 480, 100, 100. So that fits quite nicely into our model. We don't have a problem with that. However, step 4, there are also cases when you wouldn't want to be able to create segments which aren't able to be captured within the URI. So for example, I'm not sure if you can see it, there's a green box or green line which follows around that particular house. Which maybe if you drew a square around it, you'd get some other houses that you didn't want to talk about. You wouldn't want to try and describe that very complex line which is sort of hand drawn in the URI, you'd end up with a long string there. So the requirement, it's important to be able to express non-rectangular regions of a resource. Situations where a rectangle cannot unambiguously delineate the region of interest. This interface by the way is LEMO which is done by Bernard Hasselhoffer, a very inspiring model for us. So this is where we can start to get slightly more complex with the data model, but hopefully in video cases we'll be able to be handled by the W3C URI fragments specification. So now we add a context node. People familiar with ORE may think about proxy nodes, they're pretty similar. And from that context node we then have a segment description. This would be a resource that describes the area or the region, the segment of the target, that sort of is of interest. So that might be an SVG path for an image, X path into an XML document, some way of identifying a speaker within an audio track. There is work for this such as an MPX7 so we're not trying to or we certainly do not want to have to go through all of the different formats and try and work out how to specify segments. One area that we do think is of interest especially to this community is databases and datasets. How to specify slices of those things. This will obviously require a lot more research. So to kind of try and put that into an example another tweet, these galaxies but not the red one look very impressive too. We then have a context node here which has a segment description in SVG and that SVG describes this non-rectangular region here. It would then be up to the client to interpret that which is obviously media type dependent and so forth. Alright, step 5. So for this one we're starting to go further beyond existing models. The requirement then is that you be able to annotate multiple regions or multiple resources within one annotation. So I couldn't find a good screenshot of this happening with a lifeline. So I kind of fact it in acrobat by drawing a whole bunch of lines. So this is an annotation, annotating the word annotation within the handout. The requirement then the annotation should be able to have more than one target resource or segment when the annotation concerns multiple resources or creates a relationship between resources. We modeled this in a particularly straightforward way simply by adding an additional target nodes. So we've had T1 up until now. We now have a second target T2. The thing to note of course is that the relationship that we talked about at the beginning applies uniformly between the source and each target. So this source has relationship P1 to target T1 and the content has the same relationship P1 to target T2. To insensiate that these two parts of the image have the most interesting clusters of galaxies. That's the content. It annotates this part of the image and annotates in exactly the same way this part of the image. So hopefully haven't lost you. This is where it starts getting slightly more exotic. One of the things that we're not sure if this should be modeled in a different way. So the number of content sources you could also multiply. So some use cases for that would be the same comment expressed in different formats. So you might have something in text and then something in MathML or XML. The same comment is expressed in different media. So I write in my string and then I record it on my microphone and I'll load it somewhere and all of a sudden I have an MP3 of exactly the same sentiment. So that could be a second content. Equally I might write my comment in English, someone thinks oh this is really fantastic, I'm going to translate it into French or Spanish or whatever. It's the same it's still an annotation in that it's my content translated. So that could be a second form of the content. And again they would have a uniform relationship from the content source over to the target. So the Hubble Deep Field image is very impressive, I could record that as an MP3 then I'd have two contents both about the same image. An alternative way of doing this would be to simply have one as the content and the other one related to it by for example DC terms has format rather than having them both as content. But then the flip side of that is your preferring one if you've got a client that say has a, is for visually challenged people they might really prefer that MP3 or if you've got one in French and one in English I might prefer it in English but someone else would certainly prefer it in French. So step six then the requirements is that the annotation be robust across time. So one of the problems with the web or problems in a bit of commerce is that at any given URI you can have totally different representations being returned. If I go to CNN one day it's different to the next day it's different to the next 10 minutes probably. So when I was talking about CNN.com what was I really talking about was it about CNN.com at that particular time or was it about the sort of semantics of the page in general. So here we have one content in blue but then across time at CNN.com for example we have a whole bunch of different things that I could be talking about. This is one of the main areas that we think we're going to be adding into the sort of knowledge about annotations and a lot of other systems have kind of used the URI web based model but totally ignored this problem. Of course this is a very good time to plug our talk tomorrow morning so please come here to talk about to hear us talk about Memento tomorrow morning. To put this into context I could have tweeted a very sad story today Tuesday 1st of December on the BBC news about Babies with HIV then here's the BBC news page it's got absolutely nothing about that still got nothing about it oh there it is next day it's gone it's gone so I need to be able to get back to that third page how are we going to do that. So solution number one we say that the created timestamp for the annotation event should be used as the date time of the version of both content and target resources unless it's specified otherwise so for example the annotation event was created on the 1st of December Twitter tweet was on the 1st of December page on the 1st of December it's all good but then I can't say did you see BBC yesterday didn't you think that story was great it's like well hang on yesterday isn't when I created the event so that doesn't work so we go back to the context node and we add another property called OAC when so this timestamp T2 different from the timestamp of the created date for the annotation is when the target should be interpreted the version of the target so if you have for example a comment on multiple multiple resources you'd have different context nodes each potentially with different OAC when properties and then you're unambiguously stating this is when I mean it to apply the third solution is simply to avoid the problem completely and annotate a stored copy of that page so we've got the internet archive or archive it and then we can simply simply push it into an archive annotate the archived version but then say this was here at this time Step 7, the obvious last step is that once we've got all of this model we then need to be able to interact with it we need a description which we call a transcription of the annotation event Google has SideWiki with a whole bunch of XML and Atea also has a description property we use the same conventions as linked data and hence ORE and introduce this transcription node which is a resource that you can get to anywhere on the web so this is the dispersed data methodology that Cliff talked about in its summary and that's the full data model we think it goes far enough to capture everything not too far to capture things which are totally irrelevant but we definitely want your feedback on it we did a bunch of background research starting with Atea obviously as a W3 standard and also looking at the comments about Atea to see what people liked what people didn't like Lima was a much more recent annotation system it's now in use by the European Library and uses similar sorts of concepts in terms of linked data Dailas is a European annotation system therefore plenty Google obviously there's an 800 pound gorilla standing around with an annotation system we can't avoid it Flickr annotations maybe a 650 pound gorilla but also tags so many many many systems have tags you could think of a tag as a very simple annotation on a resource so we've looked at them we believe that our model covers all of this as well as other requirements that we had from the scholarly community so the one area where we've totally left current practice is that existing systems are very tightly coupled the client knows how to talk to the server the one server and the server knows how to send back that information so annotator has a protocol which is very REST based which is good Google sidewiki uses ATOM for getting that annotations from the server to the client currently you can't create an annotation outside of their interface but there's a lot of requests for that obviously so those are the exceptions most of them are completely proprietary how Digo or Web Notes stores there or creates their little post-it notes for your pages no one knows so we think this is a hindrance to interoperability to the point where any protocol that ties servers and clients together is a hindrance so we are going to recommend no protocol as opposed to recommending a protocol I know what you're thinking so here's the Google model you've got your Google interface it talks the Google protocol to the Google sidewiki servers it stores them other Google clients come in talking the Google protocol to the Google sidewiki and you could be doing it on your Google droid phone which runs the Google Chrome OS and Google Chrome for the browser which runs over Google HTTPS and uses the new Google DNS et cetera et cetera this is the lock-in proprietary model as much as Google claims it's open the scary thing is I didn't actually need to invent any of these things so here's our sort of web-based protocolist approach so the client has to obviously send the annotation somewhere to store or it could send it to multiple places the server then retrieves the annotation using regular discovery techniques you could have an RSS feed of your annotations you could put them in an OAIPMH server however people normally discover things on the web and use Google to find them or it could be on demand from the client so you put it on a web server somewhere then you poke the server and say hey go get it or it could be that the server is just one place of many that you happen to send your annotation and then on the server side that one server that you sent it to could be just one place of many that you can get your annotation from and once it's a resource on the web anyone can go fetch it pull it back put it into their server which indexes say the annotations makes them available and the blue line in the diagram servers can talk to each other if one server makes an OAIPMH or an atom interface available for all of the servers all of the annotations that it has collected other systems could go in and suck down all of their annotations to create a meta annotation server so this is a much more colourful diagram there is an orange absolutely everywhere so my preferred client interface I create it by posting it on my blog say or I push it to Twitter or I just stick it on a web server somewhere that I control different harvesters can then come in suck them down index them and other clients that other people prefer can then talk to their preferred server there's some obvious consequences of this so multiple servers or aggregators or applications can all access your annotation it's just a resource on the web like any other resource client then uses whatever protocol is required by the storage server so that could be just an HTTP push you could use SCP to push it to your personal web server you could use Twitter to tweet it or whatever annotations as I just stressed irregular web resources by necessity so this isn't by design or at the convenience of the server it's by necessity and another thing that you were probably thinking immediately previous what about access control how do I have groups of servers that can access my annotation as interoperability people our immediate reaction is no you shouldn't do that and let anyone do it but that's not a realistic view so using this model we don't have to come up with our own authentication and authorization system we don't have to model groups and users all we have to do is say well it's up to you to configure whatever server you store your annotations on to only allow access to servers that you trust to distribute your annotation like any other web authentication authorization system you could use OpenID Shibuleth basic authentication whatever you want another positive consequence we think is that services can be used to extend this information in the annotation so just because you've published it someone else can come in and talk about your annotation because it's linked open data so for example a service might add extra information to increase the robustness over time or across formats it goes in inspects your annotation, inspects the target resource and then publishes something in RDF which says and it's about this particular part of the target resource you could add extra information for the robustness of the segment location text mining data mining across annotations graph mining or relationship mining across lots of annotations the possibilities are endless I see that I'd come back to this urn for strings so this is where I'm coming back to it servers can replace those urns with uris so for example say an annotation aggregator finds your annotation which has a urn for the content it pulls it down, puts it in a database the urn with an HTTP uri that it controls so you don't have to mint it the server mints it and say that it's the same as your urn so it uses your identifier for deduplication because remember multiple servers can all aggregate your annotation but it mints uris that are accessible from the web so here I am in Flickr with an image which is quite a bag I have a book marklet which says annotate that pulls me into my annotation interface which is built on J2K with J2K you can zoom in, you can move it round you can investigate the whole image quite nicely we click on this little button which says show and there here are the annotations that it's found this first one then is a rectangular region so the basic thing it's got a string as the content up here we have another non-rectangular region which we want to identify if we zoom out we then can see the top annotation which is about two people roi-fielding and set them burnously so there's an example of multiple that targets so you want to create one we'll add a title the sun so say you want to talk about the sun the sun is a happy looking dude and it's a circular thing so we'll create a circular region just by dragging it you can then drag that around you can resize it to get the right location we're going to post it to my blog Rob's annotations click create and it says annotation created and it's requested the re-harvest so it's the pull on demand go into blogger so this is bloggers interface not mine and there's the new annotation that we created it's about the flicker object and there's the string we go back if we go back to show show all of a sudden here's our new annotation in the sun click on it and there's the region that it's about here's a slightly more complicated or functional interface it's about a medieval manuscript you can see all of the transcription of it there's a whole bunch of additional options that you might want to play with we're concerned with annotations of course so let's have a look at them so here's a YouTube example I'm Christopher Dehamel you're saying my name is Christopher Dehamel blah blah blah blah or you could use slide chair as a place where you've stored your content there's the slides that can embed them it's not really about the image but it's a less somewhat related so that was an annotation on the annotation for replies you can of course have squares or multiple different regions he is using Twitter to get the string so that's the actual URL that's the resource and then the interface pulls it in or you could use an image as the thing, as the content and the reply is how very my space so that's great for images what about web pages in general so using the same interface we click on annotate it does a screen capture of it to pull it in because we've built it on J2K which is a image server zoom in to get to the point that we're interested in which is say this top server about Sudan creating new interface give it a title give it some content the plight of Sudan is pretty terrible it will draw the region that we're interested in or that it concerns click on create and again we'll get the annotation created so we've got a blogger just to show you that it's posting it there it's in reply to CNN.com oh dear, you can see what's coming up I'm sure plight of Sudan is pretty terrible we come back and let's show the annotations family abductions made yesterday hang on, what's this? so there's the current one so yesterday the article that was in that space was about family abductions so that's the need for the time robustness so in summary the collaboration is up and working we've had a whole bunch of conference calls we've done some good collaborative work the data model we have the alpha version ready for feedback which we strongly solicit but it's not a specification document yet you've seen as much as anyone knows right now it covers the use cases and requirements that we've gathered and analysed it covers as much previous work as we could possibly go through in the last four months it's based on link data and the web architecture and instead of having a protocol like we've had in the past we have this sort of protocol-less interaction between distributed servers and clients those are the URIs open annotation is the main project sites there's the OAC tech group if you've got any comments at all please join in and we can discuss them or if you'd rather not post them in the open those are our emails that we have on our iPhones as opposed to our Lionel ones the presentation as we said at the beginning is being videoed we will be posted if you want to look at the slides where they are or the YouTube video for the demo is there and I thank you all very much for your attention if you have questions use the microphone so that it can be heard CLS question is this when you've downloaded an external URI and convert it to a local URI is there any need to maintain a link from the URI that you created back to the URI absolutely and what would the reasons be so the reason or the main reason is that because you've posted it online doesn't mean that there's just going to be one server that downloads it into their system and creates a URI for it so you put your annotation up and you give it a UUID and our server one finds it and says oh I'm going to do the right thing I'm going to create a URI for this URI and say it's example1.com slash UUID another server comes along finds it and says I'm going to pull down this annotation look at it oh a UUID I'm going to do the right thing and turn that into URI server2.org slash UUID now you've got three identifiers which aren't linked at all for the same resource so if they all maintain the UUID you can then use that as the sort of deduplication key so that you could have server 4 which comes in and says okay I'm going to harvest all of these servers up together I've got these very similar ones but they've got different URIs so without the UUID being maintained as the point of deduplication that might create 20 different copies of the same annotation. I'm sorry that wasn't clear in the presentation. Are there any other questions? Ed. Uma Murthy, a PhD student been working with me on the same problem for about three or four years has a lot of good results I think you might be interested. I sent you an email about this so maybe she can join the tech group if that's okay. Yes absolutely. We've been collaborating with David Mayer and Lois Delcam at Portland State University who have been working on marks and superimposed information probably seen as at some of our digital library meetings it seems very important to separate out marking parts of objects from the other parts of this activity which I see you have a standard you refer to maybe you can comment a little bit more about that. By the marks do you mean for example the parts of documents and identifying segments because most people refer to pieces of things not just the whole thing. That's a major problem in the internet right now we can't refer to parts of things very well. We hope to use the URI segments specification coming out of the W3C for that and for parts where it's not possible hopefully some interested community will come up with a reasonably well adopted standard for describing the segment as for that media type. So for example MBeg7 has a whole bunch of different ways of specifying sections of video and audio in particular. There's a very simple way of doing it with the URI segments but that's seriously not going to be sufficient for humanities scholars uses. So we're kind of pushing the problem down the road but we think we can cover the majority of use cases either with things like SVG XPath, well-adopted web standards and the URI fragments from W3C. We'd be very, very interested in hearing about additional work in the area because we acknowledge, recognize that that is an issue that will not go away. It absolutely must be addressed. We've actually been in touch with the people of the W3C media fragment identifier group actually trying to convince them to embrace our segment approach. So their current approach is that they will allow for fragment identifiers for rather basic simple use cases such as the rectangular regions that Rob showed or for a sequence of a video or an audio recording would have you not a chapter in a book track on a CD. So really basic things. Basically, those are all by value descriptions in the URI fragment. We've been in touch proposing them to also allow by reference description. So like the fragment describing documents that we propose here the idea would be that you would have the URI of the original resource and then just like the current fragments you have a hash but then you would have a URI of a document that describes a segment of that. And the feedback wasn't positive in the sense that they the easy response is it's beyond the scope of what we want to do and then the discussion is of course closed. So that's where we're at with that. It would have been of course nice to embed it in a W3C standard but it didn't feel to us that the door was really open there. Thanks for that Rob Herbert. That's really good. One question I had was that you usually think of a context as a sort of enclosing or encapsulating bigger thing and you have your context target as the segment of the target. Is that sort of so dumb down works nicely or can you talk about that a bit? Yep. So in the same way let me go back to it. In the same way as we had proxies in ORI we wanted to have some sort of node from which to hang the segment description and OAC when for the time dimension which is in some ways the same sort of thing as a segment description. A segment in time across multiple representations or a segment of the representation. So, yes the context node is really so that you don't have to mint a new URI and for each segment which is going to make for many many many URIs which won't have standard ways of constructing them like the URI specification from OAC so say you wanted to talk about a particular path in the resource we don't want to have to put some totally arbitrary set of data into a URI so then we need a new node in the graph because we use RDF we thought it would be better to have a context node it's up for names are the least part of our data modelling problems so if there's a better name than context we are very happy to change it especially as content context is rather a mouthful so anyway we have this context node which we then hang the descriptions of one of the project partners Jane Hunter from Queensland used a very similar approach to this in previous work so we decided that I think versions of the model that we went through, particularly in this area we thought this was the the least number of new URIs being minted along with the best backwards compatibility and if you don't understand the segment description you're at least now annotating still the resource so a really stupid client that only understands content and target so let's get to the right resource as opposed to trying to resolve some UID in going that doesn't exist I'm not going to do anything is that a couple of questions we have a couple of minutes left if there are any other questions a great presentation thank you very much Tom Kramer from Stanford in your demonstration I don't know if that was proof of concept or plan for further system you illustrated the regions of interest quite well but during the manuscript page you clicked on and off and you had annotations actually overlaid on top of text is that a core part of the system and could you talk more about how you plan to annotate textual regions or textual sections of documents the short answer is no we can't really talk about it in much detail because we haven't considered annotating text within images and the distinction between annotating the depicted text and the pixels which make up that it's kind of a a firba problem but on crack right what level of which works representation expression yes it's a problem which we know will come up especially in the humanities where people love having an image of a manuscript and talking about the text that's depicted as opposed to the virtual image we hope we can do it with classes of annotation so you might have a class of annotation which is a textual annotation as opposed to a art history or art historical annotation so you could have two or a paleographical annotation if you wanted to talk about the handwriting of the text which is depicted as opposed to the text which is depicted or just the depiction so yes we hope that the classes of annotation will at least go some way towards that at the moment we're still in the sort of data modelling overall rather than really drilling down into the complicated things like that the little yellow boxes that came up weren't annotations they were hard coded things which sit in JavaScript rather than on annotation they could be done as areas with full annotation but it seemed overkill thank you that's a good question alright well thank you all very much for coming please as a final note come to our memento talk same place tomorrow morning