Warning:
This wiki has been archived and is now read-only.

Draft2 Open Issues

From Open Annotation Community Group
Jump to: navigation, search

Style

Status: Consensus obtained, documentation forthcoming

Style summary

Multiple Bodies

Status: Discussion (Jane Hunter, Anna Gerber, Jacob Jett, Paolo Ciccarese)

  • We have a special case for multiple bodies for Tags + Body.
  • There are many use cases for multiple bodies such as alternative representations, languages, formats etc.
  • We allow multiple targets, so why not multiple bodies
  • Can this be accomplished with "composite annotations" that group together existing ones?
  • There is a need of expressing translation in multiple languages of the same annotation. [Paolo]

See also Multiple Resources

Multiple Bodies

Semantics of Multiple Targets

Status: Discussion (Kevin Livingstone, Karin Verspoor as proxy, Tom Habing)

  • Are multiple targets ALL or ANY of the resources? (Unclear)
  • It is hard to reason over multiple targets when the semantics are not specified
  • Can we be explicit without introducing either unwarranted complexity, or overly restrictive rules?
  • We have alternative Specifiers and CompositeSpecifiers. Can we have CompositeTarget and CompositeBody?

Possible Options:

  • 1. Status Quo: No formal semantics for multiple targets, no defined way to add those semantics
  • 2. Mandated Any: Multiple targets are alternatives only one to be displayed, CompositeResource class for All
  • 3. Mandated All: Multiple targets are a set all of which are required, AlternativeResource class for Any
  • 4. Complete: Multiple targets are unspecified, AlternativeResource for Any, CompositeResource for All
  • 5. Deprecate: Disallow multiple targets and require AlternativeResource and CompositeResource classes

The same should apply to the multiple body discussion, and to multiple Specifiers.

See also Rob Sanderson's Proposal for Integrated Multiple Resources Solution

State

Status: Discussion (Tim Cole)

  • We recognize the need to encode HTTP request headers in State (eg for content negotiation)
  • We need a proposal for how to do this :)

Proposal for Http Request Headers in State

Annotating Resource-in-Context

Status: Discussion, no concrete proposal (Randall Leeds, Paolo Ciccarese, Anna, Bernhard, James Smith)

  • 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)

Annotating Resource-in-Context Proposals

Semantic/Graph Annotations

Status: Discussion, concrete proposal from Stian (Stian Soiland-Reyes, Tom Habing)

  • How to specify an Annotation that creates a relationship? Currently, using a Semantic Annotation with a Graph for the body.
  • Can we simplify to recommending ONLY an external resource that has an RDF representation?
  • The representation should be able to be embedded with ContentAsText for consistency.
  • Do we need properties and/or classes in the oa/oax namespaces to allow semantic shortcuts, eg color as a means of expressing categorization?

Semantics of Actionable Annotations

Status: New (Bob Morris, Leyla Garcia)

  • e.g., Data annotations with expectations

Detail at Actionable Annotations

SubClassing

Status: Discussion (Bob Morris, Paul Morris, Hennie Brugman, Jacob Jett, Paolo Ciccarese)

  • Should we, and how do we, prevent combinatorial explosion of subclasses of oa:Annotation?
  • Is "Motivation" the *only* valid type of subclass, and isn't that redefining subclassing in RDF?

Sub-classing

New Specifier SubClasses

Status: New (Tim Cole)

  • CSSSelector (using CSS Selector syntax as a Selector)
  • FragmentSelector subclassing issue. It's important to know how to interpret a particular fragment, but how can this be made explicit? SubClassing is not sustainable at the ontology level as the OA specification would need to track all RFCs and other fragment specs. Perhaps a relationship to the spec, rather than our own subclass, and a list of known specs?

OA Issues for discussion.

Serialization and Transport

Status: Discussion. Details here.

Versioning

Status: Discussion (Randall Leeds, Paolo Ciccarese, Tom Habing)

  • Can you edit bodies or annotations?
  • Should the specification say anything about it?

Versioning status.

Specific Resource zooming/scaling

Status: New (James Smith, Jane Hunter, Anna Gerber)

  • oa:SpecificResource zoom/scale: Because of the fact that some features of a video may only be visible at specific resolutions, and in consideration of challenges inherent in annotating video within the context of player plugins and apps, some implementers have suggested that there may need to be ways to express zoom level and the like for oa:SpecificResources.
  • Can subclasses of oa:Selector and/or oa:State take care of this, or is another property needed?

rules for oa:SpecificResource Identifiers

Status: New (Tim Cole, Bernhard Haslhofer)

  • Currently the core spec discourages the use of de-referenceable URIs as identifiers for SpecificResources and strongly discourages the use of URIs with Fragment Identifiers as identifiers for the object of oa:hasTarget and oa:hasBody.
  • Is this a data modeling requirement or a best practice recommendation?
  • If the former, should the spec simply mandate the use of URNs for all oa:SpecificResources?
  • If the latter, should the spec leave to a best practice doc?

W3C Accessability Recommendations

Status: New

  • What should be the relation of OA to the W3C Accessability Guidelines?
    • Is it a requirement that the best practices for OA do not make it difficult to render Annotations consistently with the Accessability Guidelines?
    • What parts of OA might impact this issue?

Documentation/Discussion Issues

Status: , (Rob Sanderson, Paolo Ciccarese (conveners), Jordan Vannoy)

  • The specification should definitely have a SPARQL example of how to get all of the full URIs for the targets of an annotation.
  • Monthly teleconferences, alternating US+Europe, US+Asia+Oceania

Textual Bodies

Status: New (Antoine Isaac, Bernhard Haslhofer, Raphael Troncy)

  • should it be possible to represent simple textual bodies as literals?
  • more details: Textual Bodies