See http://titanpad.com/YT9963R4Ha

Open Annotation Telcon 2012-08-28

http://timeanddate.com/worldclock/fixedtime.html?iso=20120828T1500

Attendees:

• Paolo Ciccarese
• Rob Sanderson
• Herbert Van de Sompel
• Leyla Garcia-Castro
• Tim Clark
• Tim Cole
• Sebastian Hellman
• Dan Whaley
• Bernhard Haslhofer
• Tom Habing
• Jacob Jett
• Stian Soiland-Reyes
• Bob Morris

Regrets:

• James Smith

Chair: Paolo Ciccarese Minuting: Rob Sanderson

Agenda

Start

Paolo: Welcome and you should have the link to here. The notes will be copied into the wiki as per the first call. We are starting from where we left off last time. Last time we discussed Style, this time Context. Unfortunately Jim who filed the wiki page cannot be on the call but there are notes on the wiki.

Context (postponed from the previous call)

A desirable use case to support is being able to annotate a resource in some constrained context. For example an image as it appears in a particular HTML page.

How significant is the use case for annotating a resource with its own URI only when it appears in the context of another resource (eg image in HTML)?

Is hasContext the right mechanism, and is it sufficiently expressive? Do we need a different mechanism for physically embedded files (eg image in ePub)?

The base requirement seems to me [Rob] to be: Annotate [part of] (resource) as it is used in (resource) This extends quickly to: Annotate [part of] (resource) as it is used in [part of] (resource) For example, annotate an image as it is used on page 4 of a PDF.

Questions:

Is there a requirement for differentiating between the resource, and the resource used in some container resource? For example, is it important to be able to annotate an image, but not have the annotation appear when that image is embedded within an HTML page?

For annotating non-rendering resources (such as CSS, Javascript etc) it might be important?

A second application of filtering, that makes me [Rob] very nervous, is: Annotate all occurrences of (selection) in (set of resources)

Suggested reading: http://www.w3.org/community/openannotation/wiki/Annotating_Resource-in-Context_Proposals

Paolo: We started talking about very simple use cases. Image has a url and embedded in an html document. If we annotate the image some use cases require we keep track that it was annotated within the html document. a simple use case: If I have a scientific document with an image and the image is not correct, I want to say that the figure is not correct, I need to keep track of the fact that the annotation was in the page. Out of context it doesn't make a lot of sense. We have had several discussions on the mailing list and have an application that already runs using this sort of thing. We worked out a couple of scenarios for how it might work. Any thoughts about the document: Link http://www.w3.org/community/openannotation/wiki/Annotating_Resource-in-Context_Proposals

Paolo: Link above. (describes bullets above) I'm looking at something that has a URI. The Question: does anyone have more complex use cases? Where do we stop? It can become very complicated -- every web page that contains X.

Rob: ePub use case as above

Bob: meta comment: Address the separate URI point: A question that comes up in lots of contexts - what in the annotation deserves to be referencable. I continually find that you don't see the potholes until you consider annotation conversations. An annotation appears and you want to say stuff about the original target of the annotation as well as the annotation, eg in quality ontrol situations or docs under development. Arbitrary complexity. Will we need a URI in conversations like this?

Paolo: Create a document and an annotation, then a second user defines a new annotation about the annotation and the document.

Bob: Yes

Leyla: Annotate the annotations?

Paolo: Scond annotation is not simply annotating the first, but keeps track of the document explicitly.

Bob: Yes

Herbert: An annotation with two targets - document and first annotation

Bob: Fine to model, but if we have some resource, it's typical to find the stumbling points like that -- what happens if we don't have a URI for that. We get in trouble with annotation conversations if it doesn't have a URI.

Sebastian: Core problem exemplified is that if you see the annotation as the end point or starting point for another process. You need to model what happens to the annotation after it was created -- another user edits or looks at it etc. Creation and serialization isn't the end point.

Bob: Conversations tend to be trees not straight line.

Paolo: Annotation not an end point. Open discussions on annotation of annotations, versioning etc. Main topic... Herbert said can we just say it has two targets. Is there a difference between target and context.

Rob: Need two constructions, otherwise would display annotations on image by itself and html by itself.

Herbert: Agree. Not sure that conversations are context use case.

Bob: Would probably model as conversation, rather than context. Conversations show if you need it or not though. Probably no use case. At worst another annotation could set the context.

Tim Cole: Think that having something along option 1 that adds additional opportunity to add context. String of annotations are more work than just an additional property

Paolo: It's a use case for you?

Tim Cole: Yes, plus Anna and Jim Smith. We definitely do.

Paolo: In Domeo we have it too. Happy to have it in a very simple way, no exclusions etc. Just annotating image in a document. ANyone else have the use case? (...) Simple scenario and see what people say on the list. One other point: Sometimes the annotation it's good to know if it was created in a context as it helps the context, but still makes some sense outside the context. Sometimes it makes sense only in the context.

Rob: First case seems like specific resource, second seems more provenance issue?

Tim Cole: Agree

Herbert: Something to do with state also. If you say it's in the context of some other URI, then you need to talk about the state of the uri. eg Temporal aspects etc, other content negotiation. Wondering if it should be included somehow in oa:State, more a general purpose context notion.

Paolo: Instead of showing image you show that it belongs to something else

Herbert: SHow the state and that it talks about a version, in context of a version of the page.

Tim Cole: Is that a new use case? Option 1 is a bit mroe complex than Paolo said. Talk separately about image version and html verison, but may be too complicated for what we need? What goes

Rob: Leave the definition open for hasSource

Herbert: Weird to have it off the annotation

Rob: Yes.

Tim Cole: Jim has off the target.

(much agreement)

Paolo: If it hangs off the target called whatever that means the annotation doesn't make sense without it.

Rob: Talk about the name? Any thoughts?

Paolo: Context relationship in annotea; compatible with our thinking.

Tim Cole: A little bit different, maybe more like selector

Rob: A bit of everything.

Herbert: Prefer an abstract term. Embedded in is quite specific, not 'only when used with' so more generic allows for future use cases. Agree "context" is so overloaded in general.

Paolo: validWith?

Herbert, Tim Cole: Yes.

Bob: validOnlyWith. Not usable by politicians :) (laughter)

Paolo: That can be in extended extensions. validOnlyWith covers one half. The other?

Tim Cole: Other things can be said outside of our vocabs. Can stil make notes between target and other things. Can interpret, but useful to know. So maybe prov but could be just outside.

Paolo: two cases - multiple targets, and keep track of where the target comes from. Example with the relationships?

Tim Cole: Second case is provenance, agree. I annotated it and got to it this way. Seems provenance of annotation. Want to say annotating image of frog and annotation stands on its own, but frog is a reflection of "frog images" collection. eg would just use dc:isPartOf without adding new entries to ontology

Paolo: Expressed from annotation or image?

Tim COle: image to collection. Outside the annotation. Consumers might drop it. If it only makes sense with the collection, eg this is the best pic in the collection, then we need to have the context of the collection. If it's just a good picture of a frog, and it happens to be part of the collection, the n the annotaion is still valid

Paolo: A more abstract example - part of some other information artifact not a document

Tim: If a book is a collection of pages comes up. Gets interesting.

Bob: With images, use case in biodiversity multimedia. One thing had to provide as metadata is need to say things about more abstract thing than set of pixels. Need to be able to talk about all sets of pixels that represent the abstract image. frog image is not just single representation, lots of other representations. Ability to annotate abstract.

Rob: Dan B - hamlet

Bob: Extensive and Intensive requirements. All on the table is extensive.

Tim: Suggested that we're going to have to get used to the idea that there'll be identifiers for these things. Need to have identity for Moby Dick as a Novel. Short of that it's hard to imagine how to get there.

Bob: Agree, lets move on

Paolo: Every picture of the Eiffel Tower. If that's the target, then any annotation with the target would affect.

Rob: Agree.

Paolo: Is there anything in prov about context -- not the valid one but for the annotation.

Stian: Not directly. Specialization and Alternation, more specific version of the thing. but not where you can relate the context. Not really collections.

Bob: Doesn't feel like a provenance issue. Prov is how do I know this is what it claims to be. I've already accepted that, now I want to know more like evidence, want to know why I should believe this thing. Provenance only one reason to believe, this is more the reasoning than the authenticity

Tim: approach of agents taking actions on resources during lifecycle. Lifecycle of the annotation before it was in the data model was what the agent was doing to get there. Not to do with validity but maybe it's too much of a stretch. Can't think of a term.

Bob: Probably isnt' a provenance problem.

Tom H: Thinking of it in terms of versioning.

Tim: Where is it hanging and what is it?

Paolo: Go back to what Herbert said, veiwer is relating the "context" to the target. Annotating this target and it happens to be in some thing else. With State would be one way, but problem is that it becomes complex.

Herbert: I agree. At the same time must anticipate the cases, eg image case, this version of image doesn't belong in this version of the text.

Rob: More to do with the validOnlyIn case not discovery

Tim: Do we have a use case for the looking at version?

Paolo: Christian said he was doing something. Need to keep track of what was being looked at.

Tim: Context -- origin of the annotation or target.

Herbert: Very simple case, download a pdf from elsevier, annotate it on desktop, has a file:/// uri and want to expose the annotations. Clearly I want to refer to the PDF from elsevier. Big use case! Provenance issue here?

Stian: prov:specializationOf (and prov:Quotation derivation) issue where you can use both URIs. Example:

  <file:///tmp/blah.pdf> a prov:Entity ;
       prov:specializationOf <http://elsevier.com/blah.pdf> ;
       prov:wasDerivedFrom <http://elsevier.com/blah.pdf> ;
       prov:qualifiedDerivation [ a prov:Quotation;  
                                            prov:entity <http://elsevier.com/blah.pdf> ] ;
       prov:wasGeneratedBy :downloading .
   :downloading a prov:Activity, :Downloading ;
       prov:endedAt 2012-08-05T12:00:00Z .
   <http://elsevier.com/blah.pdf> prov:specializationOf doi:10.334.12 .

Bob: Agree there's a provenance issue for origin. further more there's from a prov point of view I'd expect even more. How was it fetched for example. State of the original document might be an issue. Without the origin of the PDF, it could be useless just to claim it came from elsevier. It's a hint but it's not something that a machine could reason upon.

Paolo: State would allow complexity.

Bob: Mixed mind here. Big use case, there are two things that could get out of prov, does the particular state of the resource is it reasonable to apply the body to this resource. Would be answered by context. Has someone cheated me here? Is this actually what elsevier published. That's the provenance issue distinct from the context issue

Tim: I think those get addressed in different ways. Consider case I want to annotate article with a DOI. turns out available from elsevier, science direct, ebsco, from my stand point I'm annotating doi X i'm just oign to do that. On the target node I may add extra info to say it was from EBSCO or its dc:source was science direct. That may be important but not to the annotator, who is just annotating the resource with DOI X.

Herbert: Stay with the example. Say X is the target. What's the URI

Tim: Publisher source . http://dx.doi.org

Herbert: that's the splash page.

Tim, Tom H: True.

Herbert: Need to talk about the issue, maybe in different call.

Tim: we re annotating a PDF file

Herbert: Yep. If publishers put the DOIs in the XMP metadata, which they don't do, we could track. Could use to glue together but without a consistent approach we have toglue together in the annotation. hence the question.

Tim: Use the PDF 's URI. Probably wnt a property on the target node to say related to the doi, outside of anntation ontology

Herbert: solving a publisher problem

Paolo: We do that all the time. always annotate the urls of the document. and keep track of the possible IDs, eg pubmed etc. Keep track of everything. Never really annotate a DOI in general. If had to, would refer to ?

Tim: Agree, but then put the idnetifiers on outside vocab so at a location where can't get it, can use doi to get the PDF from elsewhere Not needed context to make it valid.

Herbert: big use case. Would be good to have in the cookbook. Express equivalence.

Paolo: Agree. Lots of counter examples for everything. DOIs, different publishers enough to motivate reactions. Eg online version before print version with same DOI. Lots of use cases, separate topic. Could it be part of the state? This is the URI I annotate and it has these other IDs. Other ontologies.

Stian: Sounds like reimplementing FRBR model?

Herbert: Just have to show an example of how it could be done

Paolo: I can contribute examples. Create a spearate page to come to agreement if others do it differently.

Tim: Do we need more than validOnlyWith? Are there use cases that can't be dealt with via other ontologies.

Paolo: Not sure. Maybe we defer? Tim, logistics?

Tim: Jacob has sent out emails and confirm hotel.

Jacob: Everyone who we booked rooms for should have received an email.

Tim: Agenda. Should post a bit ahead.

Bob: Serialization and transport. Issues to their own page?

Rob: Yes please. Open Issues page as ToC.

Paolo: Thanks everyone. Keep paying attention to the list for other discussion. Also on the wiki pages, take a look there.Comments and contributions, just add them there or send to the mailing list if you don't want to edit directly.

Publishing and Network Transport (postponed from the previous call)

• Which of: prov:alternateOf / skos:closeMatch / oa:equivalent / other?
• What status do we give to JSON-LD? (Example provided by Randall Leeds: https://gist.github.com/3462300)
• Should the core/extension documents only express the model and the network layer be moved to a different document?

Multiple bodies/ Composite Annotations

• Continue on-list discussion

See also: http://www.w3.org/community/openannotation/wiki/Multiple_Bodies

Focus Groups

• Checking in with volunteers leading the focus groups on the different open issues, especially:
  • Versioning and Dynamic Annotations (Paolo will give an introduction to the material posted on the WIKI http://www.w3.org/community/openannotation/wiki/Versioning)
  • Specification of State
  • Data/Semantic/Actionable Annotations
  • Semantics of Multiple Targets and Bodies

(please see http://www.w3.org/community/openannotation/wiki/Open_Issues )

Any Other Business