Re: Notes from Tuesday's Open Annotation Community Group meeting in Manchester

Thanks very much for these notes, Jacob!

> "No particular Action Item was generated but discussion of this and the other issues raised above is highly encouraged."
>

That's great, given that few of us could make it to the workshop. How are we proceeding? I guess the chairs think some issues have higher priority than others. And it could be counter-productive to start all at once. And what's the time frame?

Best,

Antoine



> Hi all,
>
>
> Below are the meeting notes from Tuesday's in-person meeting of those members of the Community Group who could be present. While a number of action items were generated, no changes were proposed to the current specification.
>
>
> Regards,
>
>
> Jacob
>
>
> _____________________________________________________
> Jacob Jett
> Visiting Project Coordinator
> Center for Informatics Research in Science and Scholarship
> The Graduate School of Library and Information Science
> University of Illinois at Urbana-Champaign
> 501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
> (217) 244-2164
> jjett2@illinois.edu <mailto:jjett2@illinois.edu>
>
>
> Notes from the Open Annotation Community Group Meeting
>
> 25 June 2013, Manchester, U.K.
>
>
>   Members present:
>
> *Paolo Ciccarese*, Massachusetts General Hospital & Harvard University
>
> *Tim Clark*, Massachusetts General Hospital & Harvard University
>
> *Anna Gerber*, The University of Queensland
>
> *Jacob Jett*, University of Illinois at Urbana-Champaign
>
> *Bob Morris*, University of Massachusetts - Boston & Harvard University
>
> *Rob Sanderson*, Los Alamos National Laboratory
>
> *Jim Smith*, University of Maryland
>
> *Lutz Suhrbier*, Free University of Berlin
>
>
>   Agenda Items:
>
> ·Should rdf:List be a mix-in rather than referenced object for oa:List?
>
> ·Should we just use Alt, Bag and List directly making oa specific classes, e.g., oa:List, unnecessary?
>
> ·The oa:SemanticTag as a class is still ugly, is there a better solution?
>
> ·Can we offer a mapping to prov for specific resources (e.g. for time)?
>
> ·Rather than stick with our current arm chair list, should we provide more clarifications and validation for Motivations?
>
> ·Should we spin off specific resource and selectors to its own independent group?
>
> ·When would/should we move to a Working Group?
>
> ·What will we do about cnt if we go to a Working Group, as it’s not going to be stable?
>
> Added Topics
>
> ·OA Primer & Cookbook
>
> ·Aggregating annotations
>
>
>   Open Annotation Primer & Cookbook
>
>
>     Primer Document
>
> In order to provide additional documentation that is easily accessible to developers who are new to the OA specification, Paolo has been drafting a Primer document. The draft is available at: http://www.commonsemantics.com/oa/Open%20Annotation%20Data%20Model%20Primer.html
>
> -Also - http://tinyurl.com/ohq49yf
>
> Paolo needs more worked examples from the community so that the final document can be as concrete as possible. Some possible examples suggested include:
>
> -The Flickr proof-of-concept annotation importer developed at UIUC (see http://quest.grainger.illinois.edu/Annotations/Display/Flickr)
>
> -Some form of "like" annotation: presenting a generic example and then discussing the different approaches, e.g.,:
>
> oGoogle's +1 API (see: https://developers.google.com/+/web/+1button/#plusonetag-parameters)
>
> oFacebook Like: (See: https://developers.facebook.com/docs/reference/plugins/like/ and, https://developers.facebook.com/docs/reference/opengraph/action-type/og.likes)
>
> Also discussed as a possibility for the primer or cookbook:
>
> -Slideshare (example for scope and fragment) http://blog.slideshare.net/2011/07/29/friday-tip-create-a-permalink-to-a-specific-slide/
>
> oNote: There is an open question regarding how to represent the selector if the specific resource is within an embedded resource such as Slideshare’s presentation widget or Youtube’s video embed widget. It is possible to embed the slidedeck and specify which slide to start from as a paramenter of the call... but it uses the full URI of the slidedeck and not the URI/slidenumber. Members at the meeting thought it might be better to avoid this example due to its inherent complexity
>
> oAn embedded image example, e.g., http://zoom.it/ was suggested as an alternative.
>
> oAdditional general examples will be solicited from the OA Community.
>
> Examples will be illustrated as graphs with sample serializations provided. Leveraging Queensland’s LoreStore application, sample serializations for each example will be provided in a variety formats. The document will by default display JSON-LD, which users can change to view other formats such as N3 and Turtle.
>
> *Action Item: *Collect additional simple, practical implementation examples from the OA Community.
>
>
>     Cookbook Document
>
> After a primer document containing simple examples has been produced, the cookbook document can be used to showcase examples making use of domain specific vocabularies. These domain specific examples will be solicited from the OA Community.
>
> *Action Item: *Once the primer document has been completed, collect domain specific examples for the Cookbook document from the OA Community.
>
>
>   Mapping oa:when and oa:State specifiers into Prov
>
> Mapping into the Prov ontology was discussed since Prov already has methods for segmenting resources by time. This would allow us to eliminate oa:when and other oa:States in favor of using equivalent Prov properties and potentially additional properties. This line of consideration seemed promising at first.
>
> Prov Specialized Entities:
>
> http://www.w3.org/TR/2013/REC-prov-dm-20130430/#term-specialization
>
> http://www.w3.org/TR/prov-o/#specializationOf
>
> Elimination of oa:SpecificResource in favor of prov:Specialization seemed to be possible at first but close examination of the prov:specializationOf property reveals that, while similar to oa:hasSource, prov:specializationOf lacks the spatial segmentation semantics that oa:hasSource communicates. While oa:hasSource is definitely related to prov:specializationOf, the two properties have different scopes and so are not identical. Still not sure if oa:State properties can be replaced with equivalent Prov properties.
>
> *Action Item: *Rob will add to Appendix B of the spec that hasSource is related to but not the same as prov:specializationOf.
>
>
>   Selectors/Specific Resources – Generalizable
>
> Since selectors and specific resources seem to be generalizable beyond annotations to methodology for segmenting and selecting any Web resources it was suggested that we spin them off into a separate Community/Working Group. All thought that in the long term this is probably possible but there are too few examples of selector types in the specification to move forward at this time. More use cases and examples need to be collected from the OA Community in order to build enough support and stakeholders for a separate group effort.
>
> *Action Item: *A page will be added to the wiki to collect use cases for additional selector types, e.g., QuerySelectors introduced by FilteredPush project.
>
>
>   OA Working Group Question
>
> There is growing interest in OA by larger organizations; however, the stability of the model is acting as a barrier to corporate uptake. Moving the spec to a W3C Working Group would considerably ameliorate this. On the downside, only W3C members could be members of the Working Group. This would exclude some stakeholders from having input unless they were invited experts of some kind.
>
> NISO was suggested as a possible alternative standards track venue, but it lacks the kind of impact that a W3C Working Group has. It was also suggested that we could join an existing Working Group, e.g., the Media Annotation Working Group; however, this Working Group seems to have wrapped up or run out of steam in 2011.
>
> In order to proceed with forming a Working Group, the Community first needs to find out:
>
> 1.How to get charter?
>
> 2.What are the requirements for implementation/tests?
>
> 3.Ditto with regards to industry partners, etc?
>
> *Action Items: *Rob and Paolo to discuss the Working Group requirements in greater detail with Ivan [Hermann].  They will also get in touch with Markus [Gylling], re: IDPF, etc. engagement.
>
>
>     What to do about the stability of the Content in RDF standard if OA moves to a Working Group?
>
> CNT is not a stable specification, as it has not been endorsed by the W3C. CNT has been very beneficial for building working implementations of OA. There is an open question regarding what we could do to help stabilize the Content in RDF specification if OA moves to a W3C Working Group.
>
> One possibility would be to have them join the OA Working Group. Content in RDF could at least be put into the OA Working Group charter. They would allow them to essentially get standardization for free.
>
> *Action Item: *The OA Community should talk to the CNT Community once the question of moving OA into a W3C Working Group has been resolved.
>
>
>   RDF:Collection entities
>
> The oa:List entity was discussed along with oa:Choice and oa:Composite with regards to replacing them with their rdf equivalents (rdf:List, rdf:Alt, and rdf:Bag). Consensus from those present was that while there seemed to be a lot of cross over between the two List entities, rdf:Alt and rdf:Bag didn’t seem to be truly equivalent to what is expressed by oa:Choice and oa:Composite. Those present also felt that changing the spec at this junction could stifle its uptake.
>
> *Action Item: *Keep the OA multiplicity entities as they currently are. Can re-examine this issue down the road.
>
>
>   Serialization of lists in JSON-LD
>
> It was brought up that json-ld does not support lists with identities. While lists in OA are one of the more peripheral use cases it would be very useful from a consistency point of view if they could be serialized using a structure like:
>
> { @id:X
>
> Order:[A,B]
>
> List:[A,B]}
>
> Rob has asked the JSON-LD folks to add this type of serialization to their model in the past but it was overruled as the JSON-LD folks didn’t feel it to be a compelling use case.
>
> See: https://github.com/json-ld/json-ld.org/issues/75 and http://lists.w3.org/Archives/Public/public-linked-json/2013May/0017.html
>
> *Action Item: *Rob will try again with JSON-LD people to get lists with identities. If their answer is still no, then just leave it as is until OA moves to Working Group as using oa:List is not a big use case in the OA model.
>
>
>   Translations and Rights
>
> Paolo pointed out that there is a need for a property that links Bodies or Targets (e.g., Body1 isTranslationOf Body2) to one another as translations, e.g., an isTranslationOf property. Using prism:isTranslationOf was suggested.
>
> There was also a suggestion from the iAnnotate meeting that more support for rights properties be added to the model. This might complicate the model with properties whose semantics are uncertain. For instance if party A holds the rights over an annotation Body and party B holds the rights to an annotation Target then what rights could be claimed by party C (who is making the annotation link)?
>
> *Action Item: *Solicit additional opinions on rights and translation properties from the OA Community. If there is sufficient need by the Community then add in these features through a Best Practices document, e.g., by using prism:isTranslationOf and http://creativecommons.org/ns (for rights properties).
>
>
>   Semantic Tags and Motivations
>
> The current oa:SemanticTag class represents a specialized form of Body. This class is asymmetrical with respect to annotation targets.. The group considered if there might be a better way to do this but the Semantic Tag use case was agreed to be a core use case by all.
>
> Similarly, the core types of motivations seem to contain many motivations that a duplicative. Unfortunately there was no agreement on which motivations, if any, could safely be merged into others. A oa:Transcription motivation was suggested as an addition to the list of core motivations. More thought seems to be needed on this issue.
>
> *Action Item: *Semantic Tags and the Motivation list will remain as is. Additional opinions on these issues will be collected from the OA Community.
>
>
>   Aggregation of Annotations
>
> Lutz Suhrbier brought the annotation use cases from AnnoSys to the meeting. They model annotations with multiple bodies and targets which are part of an biodiversity collections metadata digitization and editing workflow. The AnnoSys use case needs a property, in addition to annotation, that relates the individual bodies to the individual targets, i.e., something that denotes how the body is related to the target beyond annotating it. This relationship expresses something like "this body was created by the annotator when examining the given resource". Where the resource is an XPath selection in an XML document, but it could also be in other use cases, such as a field in a database, etc.
>
> To meet their use case needs AnnoSys is using the oa:hasScope property to express this relationship but the semantics of oa:hasScope are not an exact match for the AnnoSys use case. It is not as strict as desired, but currently appears to be, semantically, the closest way to express the AnnoSys use case using the current OA specification.
>
> Under the OA model the best way to do this would be to have separate annotations that communicate the “how” through a motivation. If grouping is a primary consideration, e.g, because the annotation is a series of machine operations then, the separate annotations can be grouped together using an ORE Aggregate or similar structure. Another possible solution within the scope of the OA model would be to use named graphs as the annotation’s body. One of the features of the current OA model is that the hasBody/hasTarget properties avoid the necessity of having additional Body/Target relationships. Motivation is provided so that annotators can provide additional details on how the body annotates the target but, motivation does break down if there are multiple bodies and targets. If more explicit relationships between the bodies and targets are needed then the object may not be an annotation.
>
> Concerns were raised about both of the proposed solutions, as it was pointed out that other constructions, like creating multiple annotations, neglect the fact that the AnnoSys Body/Target relationships cannot be correctly interpreted if they can be treated as individual annotations. A construction aggregating multiple annotations as targets under the ceiling of a meta-annotation and potentially assigning the oa:linking motivation, may mislead consumers to interpret that annotation as a annotation about all the annotations grouped as targets of the ceiling annotation. This also applies to ORE constructions, as a consumer will have to know that they need to query for a oa:linking motivated annotation (or a rdf:bag construction or similar collection object), in order to check if that particular annotation is an annotation on its own, or only part of an annotation with multiple bodies and targets. This will potentially lead to massive confusion and misinterpretation.
>
> No particular Action Item was generated but discussion of this and the other issues raised above is highly encouraged.
>
>

Received on Monday, 1 July 2013 18:39:01 UTC