Summary of 10/28 TPAC f2f meeting

Dear all,

The raw, completely unedited, but reasonably readable minutes of the
meeting yesterday at TPAC are online at:
http://www.w3.org/2014/10/28-annotation-minutes.html

To summarize the consensus points:

* There was a request from the CSV Working Group to allow strings directly
as the body of an annotation.  This also came up in the community group, as
many may recall.

The consensus was to accept the request with the following conditions:
-- Only plain xsd:strings are supported.
-- As soon as the body has any other datatype, language or property, the
current resource model must be used.

Thus the following becomes a legal annotation:
{
  "@type": "oa:Annotation",
  "oa:hasBody": "This is my comment",
  "oa:hasTarget": "http://some.uri/index.html"
}

A consequence is that external bodies MUST take the form:
{
  "oa:hasBody": {"@id": "http://some.uri/body.txt"}
}

(But note that targets are unchanged and must always be resources, thus
allowing just the URI as a string in the JSON-LD serialization)

* For the structure of the embedded text, the WG will engage (again) with
the editors of the ContentAsText document to ask if the WG can take the
**necessary subset** of that work through the standards process.  If they
are against that, we would use our own structure.

* The simplification of the Multiplicity constructs was discussed and a new
proposal was agreed upon.  The Composite resource will be retained with the
existing predicate oa:item.  This ensures that Composites are true sets.
Choice and List would change to having a oa:members property which has
rdf:List as its range.  In JSON-LD the serialization for all three would
have the same structure.

* There was agreement that levels of conformance were generally helpful for
communicating expectations for implementation.  A baseline level of
conformance might require only the above literal bodies, whereas a more
fully featured level would add the requirement to support external bodies.
The levels will increase monotonically, and thus everything required at
level 0 is required at level 1 plus additional requirements, everything at
level 1 is required at level 2, and so forth.

The editors will explore how to include levels in the documentation, either
in the specification proper, or as an external document that overlays the
requirements.

*  JSON-LD will be used as the primary syntax for examples.  There was a
general desire to retain the availability of the Turtle examples for those
who find that serialization easier, and to allow for future expansion for
other serializations such as RDFa, HTML or other.  The editors will explore
how to make the additional serializations available without decreasing the
readability or understandability of the specification.  The first option to
be explored is a tabbed interface, with JSON-LD as the default open tab.

* We will not split the Annotation resource into two, the conceptual
annotation and the document that describes that concept.  However, we will
explore the semantics of annotatedBy/annotatedAt and how communities can
extend the provenance information surrounding the annotation.

Any corrections to my memory and interpretation are very welcome :)

Best regards,

Rob

-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305