Warning:
This wiki has been archived and is now read-only.
Draft2 Open Issues
Contents
- 1 Style
- 2 Multiple Bodies
- 3 Semantics of Multiple Targets
- 4 State
- 5 Annotating Resource-in-Context
- 6 Semantic/Graph Annotations
- 7 SubClassing
- 8 New Specifier SubClasses
- 9 Serialization and Transport
- 10 Versioning
- 11 Specific Resource zooming/scaling
- 12 rules for oa:SpecificResource Identifiers
- 13 W3C Accessability Recommendations
- 14 Documentation/Discussion Issues
- 15 Textual Bodies
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
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?
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