Web Annotation Working Group Teleconference

<azaroth> trackbot, start meeting

<trackbot> Meeting: Web Annotation Working Group Teleconference

<trackbot> Date: 30 September 2016

<azaroth> Chair: Rob_Sanderson, Tim_Cole

<csarven> In the process of joining the call.

<azaroth> PROPOSED RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/09/16-annotation-minutes.html

<TimCole> scribenick: TimCole

<azaroth> +1

+1

<ivan> +1

RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/09/16-annotation-minutes.html

Issue Updates

<azaroth> Git: https://github.com/w3c/web-annotation/issues/354

azaroth: The appendices need to be marked informative rather than left blank defaulting to normative
... azaroth has made updates showing all except extension as informative

ivan: if C is left normative then we have to test.

azaroth: a good reason not to leave C normative
... propose all vocab appendices be informative

ivan: still requires editorial action, correct?

azaroth: correct

Issue 355

<azaroth> Git issue: https://github.com/w3c/web-annotation/issues/355

azaroth: this is in relation to TPAC discussion about CG, WG, IG making changes to namespaces, because namespace docs are not normative
... however, these changes could affect normative sections and constraints
... propose adding a comment to namespace clarifying our intended direction for document, requiring changes have to come through a WG

ivan: not sure how to say properly
... hypothetical- a new publishing WG next year decides it needs to define a new selector
... unless this new selector references the Annotation specs, couldn't add to oa namespace

azaroth: yes, they can add to their own namespace, but not ours

ivan: are we going to far the other direction?
... can we be more wishy washy

bigbluehat: one of the groups interested in this is the Soc Web WG
... they have a term that they would like to LDP (for notifications) and they are having a problem getting this done
... vocab extension discussion is growing
... so we need to leave open to eventual solution

azaroth: would ivan's wording, e.g., extension must come from a WG that has established expertise

<ivan> for example, "Any changes to this document MUST be from a Working Group in the W3C that has established expertise in the area"

azaroth: we can't enforce, but we should make our feelings known

bigbluehat: we need to be clear whether we want to allow CGs to add extensions.

<bigbluehat> +1 to ivan's wording..."established expertise" being sufficiently vague, but also exciting ;)

csarven: probably would be best to leave to WG, not CG

<azaroth> +1 to Ivan's wording as well

csarven: we need confidence that the group making the extension has knowledge and is committed, which is more likely to come with WG rather than CG or through a note

<Jacob> +1 from me as well

csarven: should do our best to preclude random extensions and changes

<bigbluehat> +1 to proposing ivan's wording as a resolution

<rhiaro> +1 ivan's wording from the sidelines

azaroth: any objections to Ivan's wording?
... none heard, let's move forward with this as an editorial change

ivan: where does this text go?

azaroth:

<azaroth> Git Issue: https://github.com/w3c/web-annotation/issues/357

azaroth: just into the namespace document

issue #357

azaroth: from testing, should it be allowed to have TextualBody as the source of a SpecificResource
... technically it should be allowed (a TextualBody is a Resource)
... but current language seems more constraining in how TextualBody is used
... allowing would make it possible to use styleClass and renderedVia on TextualBody
... also a TextualBody of Anno A may become the Target of Anno B

,,, does this need to be clarified?

ivan: yes we acknowledge that it is allowed, but don't change the document

<Jacob> +1 to ivan

<bigbluehat> +1

ivan: if we start looking at use cases, we could end up in a lengthy discussion

<azaroth> scribenick: azaroth

TimCole: It came from some real annotations at Princeton, they were using purpose this way. I pointed out they didn't really have to. Some early testing discussions was that we didn't really want this. We can change the tests, and happy for people to ask questions that might be clarified in email or later documents
... As Rob says, the model doesn't conclude this either way, and there'll be some confusion around purpose as there's two ways to handle purpose in the model

<TimCole> scribenick: TimCole

azaroth: proposal, make sure tests allow, but no change is really needed in the specs. These are edge cases and we now know how we feel about this
... result is we close the issue (Ivan has done).

issue #358

azaroth: this is just a bug
... the context has a different term than we have in the model
... fix is to change term in context
... context is not normative, so we should be able to modify now without an additional process

ivan: also found a couple of issues with the context document, so let's fix these as soon as possible
... also found issues with the namespace document

<azaroth> Git: https://github.com/w3c/web-annotation/issues/359

ivan: so let's change and Ivan will update

azaroth: the other issues are #359 and #353

<azaroth> Git: https://github.com/w3c/web-annotation/issues/353

azaroth: #353 is a duplicate of one Greg already submitted
... so editors will fix (azaroth) and pass on to Ivan
... azaroth will close

issue #360

<azaroth> git: https://github.com/w3c/web-annotation/issues/360

latest issue is about use of rights

azaroth: not clear from an ip perspective what an annotation is, so what is the rights statement conveying
... second statement was we said that the statement must be a uri but can it be a json instead?
... bodies and annotation each can have separate rights statements
... do we need to make any changes, beyond responding to clarify what the annotation is

<bigbluehat> add a license to target in the example also?

<bigbluehat> the text is great

<bigbluehat> or maybe expand the example to show multiple bodies?

ivan: text fairly clearly says what the rights statements applies to
... maybe one or two words can be editorial altered but...

azaroth: second part -- must be iri, can it be embedded json?

<bigbluehat> can we say Resource?

azaroth: not certain what they meant be embedded json
... is it a description of a resource? or something random?

ivan: think what was meant is that in some cases we want a complex resource there
... e.g., a blank node with some properties

<azaroth> " There may be at exactly 0 or more rights statements or licenses linked from each resource, and the value must be an IRI. "

azaroth: didn't want to overcomplicate the rights statement, so went with an iri rather than "resource"

ivan: can respond that this was intended

TimCole: we tested it that way too

ivan: then we can respond that changing from iri would be a normative change which would complicate the CR
... is this important enough to reopen the CR to make a normative change?
... if there are valid use cases here, we record them in git with an eye towards revising in version 2
... Rob please respond to him so that the issue is properly closed

Testing, CR time planning

TimCole: CR ends today
... not certain that we have 2 implementations of everything to be tested
... what would be realistic to get the testing done
... just made some changes that tweak the tests

<ShaneM> https://w3c.github.io/test-results/annotation-model/README.md

ivan: looking at the model report (from Takeshi), 1st block are the required features
... 2nd block is optional?

TimCole: 1st block determines that specific resource wasn't misused
... 2nd block determines that specific resource was used
... textual body also implemented now
... once we have Rob's implementation and Europeana's implementation then we will be very close to 2 implementations

ivan: can see two fails (content locator and id must match) and (target iri)

azaroth: these are bugs in line to be fixed
... https still getting it, as for paging, not enough annotations to test yet

ivan: will everything be ready to start the last round of testing[?] by the end of October?

azaroth: can take the output from the protocol servers and reuse for testing the model

TimCole: embedded textual body only has one implementation
... body value

azaroth: generated we will get from the protocol servers

TimCole: but not part of exit criteria
... embedded textual body, choice, independents, specific resource, list

have implementations of choice but not independents or list

azaroth: that's ok, they are marked at risk

ShaneM: want to confirm that things are being removed because of implementations and not the lack of tests

TimCole: these were marked at risk because while we have use cases, no one is implementing, not related to tests

ivan: by last week of October, editorial changes should be done
... know that some things are pending (from today), these must absolutely be done

<ShaneM> Note that I ened to modify wptreport to allow rolling up of results.

ivan: then tests and reports as we discussed
... once these are done then we can move one

TimCole: still implementing the changes in how we test optionals and report optionals

ShaneM: one of these written, not yet committed

TimCole: only issue is that there may not be enough implementations of bodyValue

ivan: we're still waiting for Europeana

<csarven> I'll have to revisit https://github.com/csarven/mayktso to see how close it is to being a WAP implementation.

TimCole: reference implementation = a by-hand annotation based on the model

<tbdinesh> yep

TimCole: in the report columns it is labeled AI, EB is Illinois working implementation (for the Emblematica DigLib)

ivan: if we get an implementation from dinesh and europeana then that will be 5 or 6 implementations for the model
... if europeana implements the protocol then we'll have three implementations of that

<ShaneM> I have removed the AI columns from the model result report.

<Zakim> ShaneM, you wanted to ask about removing things from spec

azaroth: one thing to note, Rob will be at Europeana in 2 weeks time, so can talk directly to Antoine

Annotation in HTML Note

TimCole: would like to start the html discussion
... haven't created the skeleton note yet, doing it this week

'... assuming that there are only 2 approaches that will be described

scribe: embedding annotations as json+ld in a script tag

<ShaneM> I wonder how Benjamin's work does it?

scribe: and embedding via rdfa (by someone else)

<csarven> https://github.com/csarven/dokieli is one

<csarven> err

<csarven> https://github.com/linkeddata/dokieli is one

ivan: can we merge this into one note?

csraven: do we really need a note on rdfa serialization? is this to make it easier for people to use the vocab to implement rdfa?

TimCole: the idea is to point to examples of how the vocabulary is useful even if the annotations are stored/transmitted directly in html
... leaving it to someone else to look at in the future

ivan: the note is not an implementation in the terms of testing, intended for users
... so that they can see how annotations can be used in/with html

<Zakim> ShaneM, you wanted to mention web platform and annotations

ShaneM: review ongoing for the web platform working group
... punts the find text api to the annotation working group

ivan: there is no work going on it, is not in our charter

csraven: use case for dokeili is using rdfa
... for use with services that are not explicitly annotation services
... might be good to come up with more use cases for rdfa serialization for the note
... might be helpful

TimCole: useful for people to see, use case csraven has outlined is compelling

ivan: don't want to make too much of a deal out of it, at a stage where work is winding down
... enough for the note to describe the use case as an example of usage
... goal is to signal that a future working group could address embedding annotations into html more formally
... but don

<csarven> Ack ivan, thanks.

ivan: want to provide to much emphasis on it right now

s /provide to/provide too

TimCole: going to create the skeleton of the note and add in the json+ld

<csarven> Happy to lead the RDFa bits

ivan: should do conver the json+ld into turtle and put it into the document too
... can use turtle in html too

<csarven> Sure

<ivan> trackbot, end telcon