Web Annotation Working Group Teleconference

<azaroth> trackbot, start meeting

<trackbot> Meeting: Web Annotation Working Group Teleconference

<trackbot> Date: 02 December 2015

<azaroth> Chair: Rob_Sanderson

<fjh> trackbot, start telecon

<trackbot> Meeting: Web Annotation Working Group Teleconference

<trackbot> Date: 02 December 2015

<fjh> Agenda: https://lists.w3.org/Archives/Public/public-annotation/2015Nov/0377.html

Announcements

<azaroth> proposed RESOLUTION: Minutes from Nov 18 approved: http://www.w3.org/2015/11/18-annotation-minutes.html

RESOLUTION: Minutes from Nov 18 approved: http://www.w3.org/2015/11/18-annotation-minutes.html

bigbluehat: objectives are to get everyone in the room talking about annotation standards using the W3C working group

azaroth: we will be off the hook for collections, paging, etc based on the Social Web group's decision

shepazu: there was some question as to whether collections would be split out or if part of the main spec
... they decided not to split it out
... meaning split out into a stand alone spec

Github Issues

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

<trackbot> Created ISSUE-26 - Https://github.com/w3c/web-annotation/issues/97. Please complete additional details at <http://www.w3.org/annotation/track/issues/26/edit>.

<azaroth> vocab: http://w3c.openannotation.org/add_vocab/vocab/wd/

azaroth: that link follows the typical styling for ontology documentation
... the issue is whether or not we want to continue with this or the existing single doc

t-cole3: I'm in favor of the split approach, but can comment on how the cross referencing may happen
... does it get tedious to do that?

azaroth: if the json-ld is in the core, we don't have to do references to every single term
... the vocab doc is responsible for determining the json-ld keys
... the model doc is just "this is what it looks like"

t-cole3: this should be good for developers, but rdf parsers will have to be a bit more careful

nickstenn: is the intent that the model doc would be detailed enough that I could conform without being a big fan of rdf

azaroth: yep

shepazu: is there a revised model spec?

<azaroth> PROPOSAL: Accept #97 and split -model into both -model and -vocab

bigbluehat: there's nothing new at the moment, but can expect a fresher copy soon

<ivan> +1

<shepazu> +1

+1

<azaroth> +1

<nickstenn> +1, enthusiastically

<davis_salisbury> +1

<Jacob> +1

<t-cole3> +1

RESOLUTION: Accept #97 and split -model into both -model and -vocab

<davis_salisbury> Agree, thanks editors!

<azaroth> Github: https://github.com/w3c/web-annotation/issues/8

azaroth: if we edit WD in branches the editors may overwrite each other
... for things that haven't been accepted yet, we may have to go back and change later
... github.io only reflects the gh-pages branch

ivan: let's take this offline, but would be good for everyone to see the evolution

azaroth: additional clarification at TPAC was this would be a method of filtering display. Not a permissions system
... the proposal is to adopt schema.org's audience pattern

t-cole3: do we really need to have our own property for this?
... given schema.org already has it

<Jacob> This issue looks like a more metadata type of issue. Since we're likely to just extend using something like DC or Schema, is there any advantage to it living in the model doc rather than a cookbook doc?

azaroth: for model there will be an example for how it should appear
... and for the vocab doc we will have a context mapping and reference to the external ontologies of schema.org
... so we wouldn't reinvent, we would just reference
... schema.org already has an 'audience' term

<shepazu> http://schema.org/Audience

ivan: in looking at the educational domain for epub, the fact that you have a book with many annotations, but that can also refer to many audiences has been considered essential by that domain

azaroth: there is a cross-domain enough problem that we want to make sure to clarify for annotations

<shepazu> http://schema.org/PeopleAudience

<Jacob> Yes, this property could be used to establish viewing restrictions

<davis_salisbury> I think the "age control" is in the github issue?

shepazu: does this have anything to do with groups?
... does this have anything to do with the intention of who the anno is intended for?
... which is separate from access control

bigbluehat: the distinction from access control is the hardest part of presenting this

<Jacob> Audience and access control are intertwined...

bigbluehat: doesn't limit my access, but does specify who they're intended for

t-cole3: I do think that we need to separate group and access control from audience
... by using schema audience here, we're only getting a handful of audience types

<scribe> ... new audience types would only be valid within your application

<davis_salisbury> I unmuted my physical phone

<tbdinesh> for re-narration we have the diversity in literacy audience types

<davis_salisbury> Can someone unmute me in zakim?

davis_salisbury: for open peer review, the idea of audience is key
... need to make clear what is in the model and what needs to be handled by the people creating systems around a journal

azaroth: we need an issue to describe how this interacts with groups

<tilgovi> +1 to Rob... 'groups' is an exceptionally overloaded term

PaoloCiccarese: the other groups can see what you're saying, but you can filter out only what applies to your group. This is different than access control. Taking this to the issue log

<tilgovi> +1 to Paolo

<davis_salisbury> +1 tp Paolo

<tbdinesh> +1 to paolo

nickstenn: the decision to include in the model should be based on whether we think others will implement in other ways. Maybe should just reference shema.org

azaroth: other communities will probably implement in other ways and this should probably go into the model

ivan: we should make the usage of the schema.org terms easier to understand to users
... what we give is a more explicit way to use

<azaroth> PROPOSAL: Accept #8, include audience in the model and vocab

<azaroth> +1

<ivan> +1

<davis_salisbury> +1

<t-cole3> +1

<shepazu> +1 (I think)

<PaoloCiccarese> +1

RESOLUTION: Accept #8, include audience in the model and vocab

<shepazu> (I think there should be a single model for groups and audience)

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

<azaroth> PROPOSAL: accept #18, use StillImage and relate to other ontologies in -vocab

<azaroth> +1

<davis_salisbury> +1

<Jacob> +1

<t-cole3> 0

<ivan> 0 (do not really undersatnd the implipactions)

<shepazu> 0

I'm not sure I understand the implications

<PaoloCiccarese> 0

<ivan> +1 to keep things unchanged if it already works...

0

RESOLUTION: accept #18, use StillImage and relate to other ontologies in -vocab

<azaroth> Github: https://github.com/w3c/web-annotation/issues/19

azaroth: proposal from july is to use the allow header to specify a PUT or DELETE when a user can edit the annotation

<tilgovi> +1 to keeping ACLs out of the model

<ivan> +1 as well

nickstenn: does that preclude having a more fine-grained implementation of permissions?

azaroth: it shouldn't.
... the server can still reject

<azaroth> Also +1 to keeping ACLs out of the model :)

ivan: is this something we have to put into the recommendation? There are many implementations of this.

nickstenn: if we aren't precise about what access control look like for the protocol, then implementations won't be interoperable

ivan: we may not have the expertise necessary for this

<tilgovi> +1 ivan

nickstenn: I agree, but think we should consult externally on what we should recommend
... I am not proposing inventing authentication protocol
... but would be worth exploring how other systems would interoperate

<Jacob> Perhaps an outside consultation is the next step for this issue?

ivan: we should not close this issue yet. Should find the people with right expertise and get opinion

<Jacob> +1 to ivan

<azaroth> +1

<ivan> trackbot, end telcon