See also: IRC log
<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
<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
<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