Web Annotation Working Group Teleconference

<trackbot> Date: 02 September 2015

trackbot, start telecon

<trackbot> Meeting: Web Annotation Working Group Teleconference

<trackbot> Date: 02 September 2015

<scribe> Agenda: https://lists.w3.org/Archives/Public/public-annotation/2015Sep/0000.html

Agenda Review, Scribe Selection, Announcements

note from Rob on Agenda item 4, https://lists.w3.org/Archives/Public/public-annotation/2015Sep/0015.html

<scribe> ScribeNick: fjh

note from Rob on Agenda item 4, https://lists.w3.org/Archives/Public/public-annotation/2015Sep/0015.html

fjh: updated wiki with how to handle issues, see https://lists.w3.org/Archives/Public/public-annotation/2015Sep/0052.html
... issues should include proposal for resolution, and possibly test cases
... minor issues like typo can be fixed by editor and acknowleded others require discussion and CfC, managed by chairs

Minutes Approval

proposed RESOLUTION: Minutes from 19 August approved, https://lists.w3.org/Archives/Public/public-annotation/2015Aug/att-0302/minutes-2015-08-19.html

RESOLUTION: Minutes from 19 August approved, https://lists.w3.org/Archives/Public/public-annotation/2015Aug/att-0302/minutes-2015-08-19.html

Data Model Changes for Roles, 3.1

Section 3.1 https://lists.w3.org/Archives/Public/public-annotation/2015Aug/0211.html

CfC: https://lists.w3.org/Archives/Public/public-annotation/2015Aug/0211.html

azaroth: CfC completed yesterday

results summary https://lists.w3.org/Archives/Public/public-annotation/2015Sep/0038.html

fjh: we had support to resolve CfC with one concern expressed by Bill Hunt who said they did not want to hold up work

azaroth: Bill Hunt not a member of group, Chris Birk an Invited Expert of the same organization did not object, representing same org, so ok

fjh: I suggest we can go ahead and make progress here, especially given the discussion following Benjamin's brainstorm on the list

proposed RESOLUTION: changes in section 3.1 of http://w3c.github.io/web-annotation/model/wd/roles.html adopted via CfC

proposed RESOLUTION: changes in section 3.1 agreed see http://w3c.github.io/web-annotation/model/wd/roles.html#proposed-model-revision per CfC conclusion

RESOLUTION: changes in section 3.1 agreed see http://w3c.github.io/web-annotation/model/wd/roles.html#proposed-model-revision per CfC conclusion

<scribe> ACTION: azaroth to update editors draft to reflect changes per 3.1 [recorded in http://www.w3.org/2015/09/02-annotation-minutes.html#action01]

<trackbot> Created ACTION-27 - Update editors draft to reflect changes per 3.1 [on Robert Sanderson - due 2015-09-09].

Option review for Data Model

<azaroth> Options: https://lists.w3.org/Archives/Public/public-annotation/2015Sep/0015.html

azaroth: two options outlined, see link, each with tradeoffs
... first is more verbose but more consistent
... second is more compact and easier to follow but more flexible and possibly inconsistent

fjh: See the linked email for details

azaroth: concern is need for code to test structure when it is not consistent

TimCole: re optimization, local application can use profile of interoperability standard, allowing optimizations
... but if wider interoperability can lose optimizations, but if local can get optimizations
... this trade off allows keeping simple cases simple

ivan: prefer to make life for users easier even if harder for application developers
... example is where can put text re role, came up in email, definitely support simple way

<Zakim> azaroth, you wanted to note profiles are like micro specifications

azaroth: responding to Tim, have seen such patterns, like micro specs, overall spec needs to be constrained
... might impact interoperability, need to be careful
... want to limit where roles are placed
... image with id, bad to put role on that image, for example

TimCole: looking at option 1 vs option 2, limitied where role can be put, small number ok
... key question is whether on annotation as well as bodies and targets.

<Zakim> fjh, you wanted to ask for specific response re option 1 vs option 2

<Jacob> basically everything that could be the object of a hasBody/hasTarget predicate but excluding the annotation node itself. I am +1 for that idea.

ivan: are there other consequences apart from what you listed in response to Doug

azaroth: haven't worked through all examples

<TimCole> motivation on multiplicity classes not thoroughly discussed in current document

<Jacob> ditto the relationship between specific resources and multiplicity nodes

fjh: should we review the individual points in 3.2 for which there was a straw poll on the list as well as option 1 and option 2

<azaroth> Straw Poll: Option 1 (Verbose, Consistent, Structured)

azaroth: lets start with options since it informs individual points

<azaroth> +1

<TimCole> -0.5 option 1

<davis_salisbury> +1

<bigbluehat> +1

<Jacob> -0

+1

<RayD> +1

<Matt_Haas> +1

<takeshi> +0.5

<ivan> 0

<TimCole> +1 option 2

<azaroth> Straw Poll : Option 2 (Compact, Flexible, Less Structured)

<ivan> +1

<Jacob> +1

<azaroth> -0

<RayD> 0

<bigbluehat> 0

<davis_salisbury> 0

0

<Kyrce> 0

<takeshi> 0

<Jacob> Looking ahead, it seems like ultimately adopting option 1 will require a larger reworking of section 5 of the spec.

ivan: repeat that need to have simple text with role, do not want that to be more complex

azaroth: keep motivation on annotation as well as roles on body/text

ivan: not sure what you are saying

<ivan> body: { text: 'asfasdfas', role: 'editing' }

ivan: I want what I put in chat as example

<ivan> body : { content: {text: 'adfasd'}, role: editing}

ivan: do not want to be forced to say this more complicated one

TimCole: we have conflation here,
... like what Ivan pointed out
... for embedded text, also for composite bodies
... because SpecificResources can appear in multiplicity class need to handle that
... example role on composite, could have role on specficResources within as well? hence limiting to specificResource might not help
... complex in abstract, so suggest we make examples

fjh: +1 to examples

<azaroth> +1 to examples too happy to do them

fjh: doug asked for that as well

TimCole: come back to it with concrete serializations in mind

fjh: +1 to option 2 now, given reminder from Ivan and Tim

azaroth: do we need examples of multiplicity constructs

TimCole: yes need to think about them, e.g. role on choice not on bodies within choice, role should be consistent

azaroth: not making it more complex given that multiplicity is already complex

ivan: multiplicity construct may become alternative to what we have now (?)
... lets solve other issues first then revisit multiplicity construct

<Jacob> So eliminate section 5 of the existing doc?

Jacob, I think the answer is no, that is not what I heard

RayD: thought Tim said for choice, should be disallowed on individual parts not for other multiplicity items

fjh: not removing section 5, suggest we attempt to include definition of roles for multiplicity as Tim suggested, examples would be very helpful

Data Model Further Considerations (Section 3.2)

http://w3c.github.io/web-annotation/model/wd/roles.html#further-considerations

<ivan> http://w3c.github.io/web-annotation/model/wd/roles.html#require-the-use-of-specificresource-for-bodies

azaroth: need role on SpecificResource

no disagreement

<ivan> http://w3c.github.io/web-annotation/model/wd/roles.html#require-the-use-of-specificresource-for-targets

<TimCole> 0 for role on targets

<ivan> 0 too

azaroth: targets 3.2.2

<Jacob> +.5 for targets

RayD: what is question
... do we need roles on targets?

azaroth: yes

<ivan> http://w3c.github.io/web-annotation/model/wd/roles.html#allow-hasrole-on-new-embeddedtextualbody-class

<ivan> +1

<Jacob> +1

azaroth: 3.2.3 allow role for embeddedContent

fjh: +1

<TimCole> +1 for role on Embedded Content

<RayD> +1

azaroth: skkp 3.2.4 renaming

<ivan> http://w3c.github.io/web-annotation/model/wd/roles.html#remove-motivatedby-completely

<RayD> -1

azaroth: 3.2.5 not allow motivation on annotation

<ivan> -1

<TimCole> +0.5 for role on Annotation if meaning is made clear

<Jacob> -0.5 ...might need this to link roles to literal bodies

fjh: -1 can be different meaning, so should have motivation on annotation as well

azaroth: propose Ray, Tim and Ivan produce examples that mirror 3.1.* showing where body or target is not specific resource

ivan: what are you asking?
... issue is 3.2.5 is whether we need separate notion, role or motivation, for annotation as a whole vs roles on invidual bodies
... seems a positive to have for annotation as a whole

+1 to Ivan's statement

azaroth: those in favor of having in more locations, come up with examples
... then can compare

TimCole: can help with this, not all of 3.1 to 3.11 may be sensible for on annotation as a whole

RayD: if you don't allow motivation at annotation level, then cannot have annotation on literal body

<Jacob> i.e., completely anonymous literals

<TimCole> This is why we need to discuss and develop examples

<azaroth> Yep

<Jacob> +1 to Ray

<Jacob> Not clear to me when motivations on annotation and bodies will really differ? Isn't it just more specific info than what might appear at the anno level?

azaroth: please send examples to list or add to github document directly

Adjourn