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

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


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.,:

o   Google's +1 API (see:
https://developers.google.com/+/web/+1button/#plusonetag-parameters)

o   Facebook 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/

o   Note: 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

o   An embedded image example, e.g., http://zoom.it/ was suggested as an
alternative.

o   Additional 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.