See also: IRC log
<trackbot> Date: 09 September 2015
<azaroth> azaroth:
<azaroth> ...
<azaroth> scribe: Paolo_Ciccarese
<azaroth> scribenick: PaoloCiccarese
<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
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
+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
+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
<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)
+1
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
<ivan> trackbot, end telcon
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Like Tim, I'll be leaving a few minutes early.// Succeeded: s/Sorry, I'm having some major connection troubles// Succeeded: s/and this// Succeeded: s/rob said this// Succeeded: s/Topic: Cross-Context JSON-LD Integration, @id and @type// Succeeded: s/...// Succeeded: s/or optimize for our usage/... or optimize for our usage/ Succeeded: s/i sa/is a/ Succeeded: s/COle/Cole/ Succeeded: s/terams/terms/ Found Scribe: Paolo_Ciccarese Found ScribeNick: PaoloCiccarese Default Present: Frederick_Hirsch, Rob_Sanderson, Ivan, Tim_Cole, Jacob_Jett, Chris_Birk, Benjamin_Young, Paolo_Ciccarese, TB_Dinesh, davis_salisbury Present: Frederick_Hirsch Rob_Sanderson Ivan Tim_Cole Jacob_Jett Chris_Birk Benjamin_Young Paolo_Ciccarese TB_Dinesh davis_salisbury Regrets: Ray_Denenberg Ben_De_Meester Doug_Schepers Agenda: https://lists.w3.org/Archives/Public/public-annotation/2015Sep/0077.html Found Date: 09 Sep 2015 Guessing minutes URL: http://www.w3.org/2015/09/09-annotation-minutes.html People with action items:[End of scribe.perl diagnostic output]