Web Annotation Working Group Teleconference

<trackbot> Date: 18 November 2015

<fjh> trackbot, start telecon

<trackbot> Meeting: Web Annotation Working Group Teleconference

<trackbot> Date: 18 November 2015

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

<fjh> Chair: Frederick_Hirsch

Agenda Review, Scribe Selection, Announcements

<fjh> ScribeNick: TimCole

Model - Activity Streams vocabulary

bigbluehat: AS vocabulary and AS 2.0 spec is still in process, not currently in a place where we can reference in our model
... discussion on github has been mostly about vocabulary and referencing semantics
... given our own (Web Anno) deadlines, we may want to do term matching but not referencing or reuse directly in our ontologies
... this way we are not dependent on AS publication schedule for our own publication schedule
... so proposal is not to reference AS vocabulary directly from our own ontologies.

ivan: is this a postponment or are we just plan not to consider it.

<Zakim> fjh, you wanted to ask if we are choosing a set of terms, our own, then provide a mapping

bigbluehat: more a postponement. we can look again and either get it in later or add a separate note at end of WG loop.

fjh: we will use terms we define and then later if we have time provide a mapping to AS.

<fjh> benjamin: correct

shepazu: regardless of schedule, if we try to coordinate terminology, can we do this without slowing us down?

bigbluehat: yes.

shepazu: is discussion just about terminology, or also about structures?
... there has been some talk in the past about coming up with a serialization of Web annotation within a AS structure
... will this idea survive into our new spec? Do we need to abstract model 1 level higher so that the terminology we use for Web annotation could occur in AS structure

<fjh> proposed RESOLUTION: defer defining mapping of Annotation terms with Activity Streams term ot later Note, currently continue with Annotation terms in use

bigbluehat: while we have talked about this a bit, it's not been written up in an issue to date.

<ivan> +1

fjh: Doug, could you write this up as a separate issue and proposal.

+1

<bigbluehat> +1

RESOLUTION: defer defining mapping of Annotation terms with Activity Streams term ot later Note, currently continue with Annotation terms in use

ivan: then can Benjamin close the issue on github?

<bigbluehat> +1

bigbluehat: yes.

One or more roles, issue 104

<fjh> https://github.com/w3c/web-annotation/issues/104

bigbluehat: this is about matching roles and motivation, such that you can use multiple roles like you can use multiple motivations

<fjh> proposed RESOLUTION: adopt 1 or more roles per issue 104 proposal

<ivan> +1

<bigbluehat> +1

bigbluehat: discussion on email list has been positive

+1

<fjh> +1

RESOLUTION: adopt 1 or more roles per issue 104 proposal

<PaoloCiccarese> +1

ivan: I will close the issue now

Model license property

<fjh> https://github.com/w3c/web-annotation/issues/100

<fjh> proposed RESOLUTION: adopt license property per issue 100 proposal

bigbluehat: license proposal had no detractors on github.
... proposal is just to use dc property to provide link to license

<fjh> I suggest editorial discretion for placing in document

bigbluehat: so we just need to focus on the license key to use on annotation and objects within the annotation

shepazu: concerned that multiple role may complicate things, e.g., you have to process more than a single value, now have to process a structure
... will encourage user agents to make multiple roles, etc.

RESOLUTION: adopt license property per issue 100 proposal

back to roles

bigbluehat: would vote to defer multiple role discussion to later call to give time for Doug to raise concerns about multiple roles

ivan: multiple roles issue has been re-opened

<fjh> RESOLUTION: keep role issue per 104 open to give more time to discuss concerns about structure

RESOLUTION: keep role issue per 104 open to give more time to discuss concerns about structure

issue 96 (dcterms:modified)

<fjh> https://github.com/w3c/web-annotation/issues/96

<fjh> modified property, make RESOLUTION: adopt dcterms:modified property per issue 96 proposal (if agreed etc)

fjh: issue 96 ties into another issue

bigbluehat: discussion around modify went beyond what the property should be to talk about how to handle issues around annotations moving around (issue 21)

<fjh> https://github.com/w3c/web-annotation/issues/21

bigbluehat: propose for issue 96 whether we should include a modify property as a should in the model

shepazu: still reading through this issue

bigbluehat: summarizing: we have a created property on Annotation, proposal is to add an additional property to express last modified date in order to record changes

shepazu: effectively date created and date modified

bigbluehat: standard date format, as used in html 5
... my proposal would defer to later call the discussion about annotations that have been moved and how to associate replies and so on as annotations move

<fjh> proposed RESOLUTION: adopt dcterms:modified property per issue 96

shepazu: okay, fine with proposal to add date modified and defer movement of annotations

<ivan> +1

<bigbluehat> +1

RESOLUTION: adopt dcterms:modified property per issue 96

Annotation updated timestamp/alsoKnownAs, `id` / `uuid`, alsoKnownAs, offline annotations

paolo: reason why these got conflated is because once you allow last-modified it does open up multiple related issues
... so consider a case where annotation is created offline on reader, then it gets transfered to my desktop, then I edit the annotation, then I put it on the Web so how is this handled as to created / modified.
... there now may be multiple copies of the annotation, different even though they appear to have the same URI.

ivan: we are on a new topic -- these need to be in a new issue(s)
... the whole issue of how identifiers interact with date modified, while important to talk about is separate from what key we use for date modified.
... there is a concern that this could inflate to a long, range-14 issue

shepazu: note, it's useful to think about what updated means in the context of the scenario Paolo raised

<fjh> we probably should start with looking at offline annotations, how to identify and relate to online annotations

shepazu: does updated mean that the annotation published somewhere else or does it mean that the content of the annotation changed?

<fjh> this should be its own issue

shepazu: personally I think it should be more about the latter

<fjh> semantics are at the application layer?

<ivan> +1 to doug

shepazu: and the issue of 2 people refering to the same URI but meaning different annotations is probably not something this WG can solve

paolo: it has to be crystal clear what we mean when we change the date modified

<fjh> versioning is another issue, e.g. what happens if a typo if fixed in an annotation

paolo: if you take an annotation that exists and it's not your annotation, you should not change it and then republished with the same URI - bad practice
... so we should provide guidance like this explicitly when defining purpose and use of date published

shepazu: totally agree

<fjh> use case for discussion - annotation sharing

shepazu: this has relevance for how we talk about sharing in our specs

<bigbluehat> let's make more issues ^_^

ivan: wondering how best to move forward on this
... if my understanding of what Paolo is saying, then we probably need some non-normative text in spec (since we can't check it)
... could Paolo come up with samples of what that text might look like

paolo: yes, that's an appropriate way to go, but may need to resolve issue 21 first?

ivan: it may be just as valid to come up with the text first to provide a framework for how we address issue 21.
... this may help keep us from going into an infinite loop over issue 21.

paolo: oaky.

<bigbluehat> +1 to getting it all written up somewhere soon

fjh: how does this all relate to the offline / online issues when creating annotations?

bigbluehat: yes, we need to address this

<bigbluehat> agree with where PaoloCiccarese is heading ;)

<bigbluehat> it's shepazu's "sharing" scenarios also

<bigbluehat> "movement of annotations around (and off/on) the Web"

paolo: but I also think about annotation storage, repositories, but once in storage someone can now re-publish and do things with these annotations

<bigbluehat> +1 to what PaoloCiccarese just said

paolo: so this is where problem of identity comes in and where being explicitly about what can be / should be done with annotations that have been aggregated / stored.

shepazu: yes, this is an important issue.

paolo: saying that offline / online is not a complete characterization.

<fjh> online annotations can also go offline, be collected etc, leading to similar issues

paolo: once annotations that have been online go into storage they may not be retrievable and if I do things to the annotation while in storage (url is now uri) and then republish, I may create problems
... so this is more than just update / modify

shepazu: it's deeper than just sharing, we need to address (at least talk about these scenarios)

<fjh> number of possibilites where URL cannot be used, purchased annotations, collected etc

ivan: can anything be put into the standard that would normatively control what's allowed?

paolo: not a lot without becoming infinitely complex, but we still need to address in a non-normative way

ivan: for example this is main reason why provenance model is so complex

paolo: yes, this was my experience on Domeo
... when you consider semantics it gets even more complex
... happy to cut the normative part as thin as possible, but having non-normative will help

<fjh> +1

shepazu: would like to add that just because we can't control what someone does out in the wild, doesn't mean we can't make the spec on this normative

<fjh> doug makes valuable point that conformance target could be authoring tool

shepazu: it's a conformance criteria on the authoring tool (rather than just the model itself)
... it will help people know (or be told) that they are doing it wrong.

ivan: the example for what you suggest is the normative text on how you are supposed to use the data- attributes in HTML 5
... I think these are normative, but may not be testable.

paolo: I would be okay with that approach.

<fjh> +1 to doug

shepazu: we have different conformance criteria for different agents, so we should be okay as long as we make clear conformance is on the authoring agents.

Minutes Approval

<fjh> proposed RESOLUTION: Minutes from 11 Nov approved, https://lists.w3.org/Archives/Public/public-annotation/2015Nov/att-0203/minutes-2015-11-11.html

RESOLUTION: Minutes from 11 Nov approved, https://lists.w3.org/Archives/Public/public-annotation/2015Nov/att-0203/minutes-2015-11-11.html

Meetings

<fjh> proposed RESOLUTION: No call next 25 Nov (US Thanksgiving)

RESOLUTION: No call next 25 Nov (US Thanksgiving)

Other Business

shepazu: talking with browser vendors about potential implementation of our data model

<fjh> Doug, Ivan can help with call after next week

shepazu: also reaching out to content vendors

adjourn