Web Annotation Working Group Teleconference -- 09 Sep 2015

<trackbot> Date: 09 September 2015

Agenda Review, Scribe Selection, Announcements

<azaroth> azaroth:

<azaroth> ...

<azaroth> scribe: Paolo_Ciccarese

<azaroth> scribenick: PaoloCiccarese

Minutes Approval

<fjh> proposed RESOLUTION: Minutes from 2 September approved, http://www.w3.org/2015/09/02-annotation-minutes.html

<fjh> RESOLUTION: Minutes from 2 September approved, http://www.w3.org/2015/09/02-annotation-minutes.html

Cross-Context JSON-LD Integration, @id and @type

fazaroth: the issue is if whether of not we want to try to collaborate with other WGs
... or optimize for our usage

azaroth: whether or not we are trying to optimize for developers doing just annotations looking to our spec

<fjh> rssagent, generate minutes

azaroth: or if we need to look at other WGs like Activity Stream
... so if we @id next to id, when we compact a document (in playground) with multiple contexts

<fjh> ivan's summary - https://lists.w3.org/Archives/Public/public-annotation/2015Sep/0099.html

azaroth: @id and id will get transferred over and processed by all contexts
... my assumption has been that we would use external context or external integration
... go through all this seems strange to me but possible
... workaround: compartmentalize JSON-LD mapping to include core annotation mapping
... into ActivityStream... include their core and so on
... a lot of inter-working group communication and alignements to make sure of the things to work properly together
... predicates that we absolutely require will be in one context and we will try to ensure that the mappings will be enforced?
... we can't avoid @id
... there is a possibility that other terms will collide in addition to @id

ivan: I think that there is one fundamental place where we should be careful about
... the distinction between only those that implement our own or multiple
... or better people that are not implementers but they want to add the annotation
... implementers are those that can do wonders so I am less worried about the difficulty for them
... I am more worried about the end users complexity
... I am against compartmentalizing that brings complexity on users
... for @id and @type, personally I don't care about the '@' but it seems that many people don't like that
... so the idea of mapping that came around
... I don't want to spend too much time on this but I keep -1
... I understand compacting creates an issue, but there is an expand that will create all the statements with URIs
... we can try to synchronize with AS but there are many others vocabularies and the approach does not scale
... in general
... we cannot solve the problem

<Zakim> azaroth, you wanted to note integraters are implementers

azaroth: I don't think we should be optimizing for end users but for developers
... the reason being that we are past the days of people opening up the code and typing in command line
... the majority of the annotations will be produced through developers
... I agree that the expand would work by turning all into RDF but will be the opposite of what we are trying to do
... I agree with the scale issue but we can at least try to not break the main ones

fjh: is the '@' really scaring the implementers?

<bigbluehat> the cost to value ratio seems in favor of sticking with @id & @type

<bigbluehat> JS devs will write annotation['@id'] vs. annotation.id

<bigbluehat> not...terrible.

TimCole: (I cannot hear properly)

<bigbluehat> url is used in ActivityStreams to mean something alongside @id fwiw

TimCole: do we have to map type to @type or to RDF:type

azaroth: @type already maps to rdf:type

<bigbluehat> see this example for @id & url being used together in AS2.0 http://www.w3.org/TR/activitystreams-core/#h-example-2

<Jacob> Tim already qualms about mapping @id to id

TimCole: I don't like to map the id to @id as they are used for many things

<azaroth> PaoloCiccarese: Was thinking about id and type. I remembered that I raised the issue to the JSON-LD people, and they said just use the quotes

<azaroth> ... It seems too complicated to do, so maybe just step back and use the @s

<Zakim> azaroth, you wanted to note @ isn't great in javascript anno.body['@id']

<fjh> proposed RESOLUTION: retain @ signs in @id and @type

<ivan> Proposal: revert the @id/@id and @type/type decision, and put this in the document as a note (asking for comments).

Ivan: let's propose to do that and put a note in the document for asking for comments from the community

<azaroth> +1

<Jacob> +1

ivan: let's make sure the request for comments is clear in the document

<fjh> proposed RESOLUTION: retain @ signs in @id and @type, reverting earlier decsion, and adding note to document

<ivan> +1

<azaroth> +1

<Jacob> +1

<fjh> +1

<TimCole> +1

<bigbluehat> +1

<takeshi> +1

<davis_salisbury> +1

RESOLUTION: retain @ signs in @id and @type, reverting earlier decsion, and adding note to document

<tbdinesh> +1

fjh: let's wait a week for feedback

<fjh> waiting week to update context file

motivatedBy on annotation

<TimCole> http://w3c.github.io/web-annotation/model/wd/AnnoLevelMotive.html

<fjh> Thanks to Tim, Ray and Ivan for really useful proposal document!

azaroth: move towards a complete decision about roles and motivations Tim and Ivan created a document
... discussion on the list with a lot of support
... everyone seem agreeing with some discussion points
... it seems I was the only one with concerns
... section 3.1 advise that there could be two vocabularies for motivations and roles and that I think is a mistake
... will increase confusion and double the numbers of items

section 3.3 I see it as out of scope

azaroth: section 3.3 I see it as out of scope

TimCole: main points: staying with a single vocabulary
... I don't feel strongly about it ( I am not sure)

<azaroth> PaoloCiccarese: Want to understand the problem you mentioned, I think it was 3.3. I think there should be one vocab. Either way it is going to be confusing.

<azaroth> ... If we have two they mimic and will be confusing. If we have two properties that do very slightly different things, it will be confusing too. So just do one to keep it tight.

<Jacob> i.e., hasMotivation on bodies instead of hasRole?

ivan: to say we have hasRole on the annotation

<Jacob> Got it. I think those are equivalent.

ivan: maybe that reduces the confusion

<fjh> why not have same range for two different properties

azaroth: that would really change the semantics. Motivation associated to the Annotation is informational only and it is the reason why the Annotation was created.
... the hasRole is an actionable property
... something the client should be paying attention to

<fjh> +1 to azaroth that meaning of Motivation and Role is useful

<tbdinesh> if it is information only, there is no problem if vocabolary overlaps

ivan: I understand but on the other hand if we are asking ourselves the question whether the values should be the same or different
... there is confusion when merging the vocabularies
... we will have confusion somewhere if we merge, the question is where it is more harmful

<azaroth> PaoloCiccarese: I agree and disagree with everything :) Motivation is something informational, but disagree that it's not operational. One thing is rendering, it could be, but a processing intensive system that motivation could be something you look at and do something as a reaction

<Jacob> Seems like motivation would be actionable in the highlighting use case.

<azaroth> ... in our case we do argumentation, so no matter the bodies are, it's actionable

<azaroth> ... The two vocabs would be merged 100%, so in the example on the list, I used community specific vocabularies like for argumentation

<azaroth> ... the motivation is to disagree. The disagreement might only be a motivation, not a role

<azaroth> The role might be comment or statement. Complicated to either split or merge. Lots of duplications if they're split, lots of weird situations where they're merged

<azaroth> ... I like the split to hasRole as I had to use it already. Would make clear in the document that the vocabs are extensible.

<azaroth> ... Not completely true that all motivations are roles

<azaroth> ... It isn't perfect, and there will be some confusion. Don't see another good solution.

<azaroth> ... I don't understand why we wouldn't allow motivation on a simple text body.

<azaroth> ... Meaning is to give why the annotation is created, not to give a role

<azaroth> ... But then the temptation is to use it as a role as the vocabs are the same

<fjh> proposed RESOLUTION: retain MotivatedBy on annotation as well has having hasRole (acknowledging issues to be worked)

<tbdinesh> motivation is role-vocabolary context

fjh: we need to agree on the co-existence of both motivatedBy and hasRole

<azaroth> +1

fjh: can we agree and have a resolution?

<ivan> +1

<Jacob> +1

<davis_salisbury> +1

<TimCole> +1 retain motivatedBy

<tbdinesh> +1

RESOLUTION: retain MotivatedBy on annotation as well has having hasRole (acknowledging issues to be worked)

fjh: counter arguments of purity and pragmatic attitude

ivan: are we keeping the same vocabularies?

fjh: we did not work that out yet

ivan: semantically speaking the 3.3 use case
... and in a purist way it is wrong, the problem is that it is very close to some other use cases in section 4
... we make a statement on annotation and not on the body

<fjh> pragmatic vs pure

ivan: on the other hand, people will use it that way
... as it is simple and quick
... we should probably leave with that kind of impurity

<Zakim> azaroth, you wanted to disagree re purity

<TimCole> agree with what you said.

<Jacob> I think this is something we'll have to live with.

<fjh> discussing 3.3 http://w3c.github.io/web-annotation/model/wd/AnnoLevelMotive.html#expressing-motivation-for-an-annotation-having-a-single-simple-textual-body

ivan: if we say that this is invalid, people will still use it. We can say it is not the preferred way
... in HTML5 there is a family of attributes with very strong restrictions in the text and people use it differently anyway

azaroth: from a pragmatic point of view, I receive an annotation with a simple textual body and a motivation and I want to process it in the same way as another annotation with the same body in a role I cannot
... by saying you can do it it so say you cannot process this

<Jacob> azaroth isn't this also a problem for highlighting?

<fjh> proposed RESOLUTION: start with single vocabulary as range for motivatedBy and hasRole and keeping property names distinct

azaroth: I see no way around that problem

<TimCole> +1

<azaroth> +q

RESOLUTION: start with single vocabulary as range for motivatedBy and hasRole and keeping property names distinct

<azaroth> +1

<tbdinesh> no. not single vocab

<Jacob> +1

TimCole: I don't see a strong distinction in terms of actionability, there are things like discovery where many community will use both in similar ways so that they can discover
... hasRole: comment and motivation: commenting
... how much the simple text body is trying to say?

<azaroth> { "motivatedBy": "bookmarking", "body": "I should read this" } != { "body" : { "role": "bookmarking", "text" : "I should read this" }

TimCole: there are many useful things that community are going to do with terms no matter where they appear
... it is also a matter of how we present this in the model

<fjh> azaroth - we need explanation of why != in terms of meaning to users

<azaroth> fjh: Agreed

TimCole: 3.1 and 3.2 to be done and leave 3.3 open

<fjh> I believe I know the answer, the annotation is not being bookmarked

azaroth: I will be happy to detail how that should be used

<TimCole> +1 to Rob's suggestion.

<ivan> +1

ivan: 3.1 and 3.2 examples will be in the document

<azaroth> proposed RESOLUTION: Be silent in the specification regarding the combination of motivation and simple textual body to see how it is used in practice

<ivan> +1

<azaroth> +1

<fjh> +1

<tbdinesh> +1

RESOLUTION: Be silent in the specification regarding the combination of motivation and simple textual body to see how it is used in practice

azaroth: 2 more decisions

<fjh> ivan: ready to publish WD?

azaroth: #1 if to allow roles on EmbeddedContent
... more concerns about having roles on the multiplicity constructs
... if Choice, Composite and List should have ?roles

ivan: to be able to move on in a more constructive manner we should have a new document asap

<fjh> ivan: suggests we get to revised Model draft that can become WD, noting open issues within, including decisions to date

<fjh> azaroth: yes can do this

<fjh> +1 to preparing new WD for publication

Adjourn

<ivan> trackbot, end telcon

- DRAFT -

Web Annotation Working Group Teleconference

09 Sep 2015

Attendees

Contents

Agenda Review, Scribe Selection, Announcements

Minutes Approval

Cross-Context JSON-LD Integration, @id and @type

motivatedBy on annotation

Adjourn

Summary of Action Items

Scribe.perl diagnostic output