See also: IRC log
<ivan> Agenda: https://lists.w3.org/Archives/Public/public-annotation/2015Aug/0153.html
<trackbot> Date: 19 August 2015
<Jacob> That's right. I call not it.
<ivan> ScribeNick: bigbluehat
<ivan> Scribe: Benjamin_Young
agenda heading toward consensus on roles and the graph/tree discussion
azaroth: if you've not registered for TPAC or filled out the survey, please do
<azaroth> proposed RESOLUTION: Minutes from 12 August approved,
<azaroth> http://www.w3.org/2015/08/12-annotation-minutes.html
<azaroth> proposed RESOLUTION: Minutes from 12 August approved, http://www.w3.org/2015/08/12-annotation-minutes.html
azaroth: any objections to the minutes from last call?
RESOLUTION: Minutes from 12 August approved
azaroth: given the size of the call, we'll push for consensus around proposed solutions on the list
... thanks Tim for the work on the wiki page
... let's quickly go through the options on the wiki page
... and see who thinks what about which
... -1/+0/+1 on each
... then let's discuss shepazu_'s thoughts on simplification
... and then craft a call for consensus that we can send to the list
... based on what we discuss on this call
<Jacob> In case anyone needs it: http://www.w3.org/annotation/wiki/Expressing_Role_in_Multi-Body_Annotations
azaroth: and see if everyone else agrees
<TimCole> +1
<Jacob> +1
+1
<ivan> +1
azaroth: let's walk through scenario 1
... no distinct roles
<ivan> -1
azaroth: what do people feel about option 0
<azaroth> Option 0: Current model
<TimCole> +0
azaroth: -1 == can't live with
<azaroth> -1
<shepazu_> -1
<Jacob> +0
+1 == prefer
<chrisbirk> -1
Scenario 1. Option 0. https://www.w3.org/annotation/wiki/Expressing_Role_in_Multi-Body_Annotations#Current_Model_.28no_role_descriptions.29
<azaroth> Option 1: Role Assignment
Scenario 1. Option 1. Role Assignment
<ivan> -1
https://www.w3.org/annotation/wiki/Expressing_Role_in_Multi-Body_Annotations#Role_Assignment
<azaroth> +0
<Jacob> +0
<TimCole> +0
<shepazu> -1
-1
<shepazu> (actually, I don't mind this in addition to native roles on bodies)
it is quite a tangle to deal with...
<shepazu> (hard for maintenance)
Scenario 1. Option 2. Role Attached to SpecificResource https://www.w3.org/annotation/wiki/Expressing_Role_in_Multi-Body_Annotations#Role_Attached_to_SpecificResource
<Jacob> +1
<ivan> +0.9999
<TimCole> +1
<azaroth> +0.9999
+1
<Kyrce> -1
<shepazu> (is there something relevant to the difference between the motivation and role props?)
ivan: this is extremely close to what shepazu wrote last night...but may need some tweaking
Kyrce: this just seems incredibly complex
... for me, and how we would be using roles, it seems fairly complicated
ivan: just for my understanding, if you don't have to use or you don't want to use role...then you don't necessarily use this structure...well...
... if I combine it with what shepazu has, it's essentially...hmmm
<shepazu> (can't you have motivation/role on the annotation as well as the body?)
azaroth: if you don't have role, you wouldn't need to use the SpecificResource
... you could just have the body be those URLs
<TimCole> no role - "body" : "http://example.org/body1.html"
azaroth: this might only apply for when there's multiple bodies
Kyrce: I don't see use ever not having a role on the body
<TimCole> role on SR - "body": {"source": "http://example.org/body1.html", "role" : "commenting"}
Kyrce: my reservation is that for every single thing
... if that's not important, then this format may be superior
... but if everything you work on is going to have a role, this feels like a lot of overhead
shepazu: I don't understand the difference between Role and Motivation
... you can have role on the annotation or motivation or whatever
... but...if you also want to have one on a particular body, then you can also do that
... the specific use case was copy-editing
... one body that says, this is my rationale, my opinion
<Jacob> The copy-edit use case is much more complex.
shepazu: and another body that separately explains it's the edit, or tags,
... that way an automated system can choose which to display, propose as an edit, etc.
Kyrce: I don't want to take too much time on this, but just wanted to put a red flag on it
... it just seems complicated
TimCole: it is a bit complex, but it is less complex than the other things we've thought of
... you'll need some kind of an object, not just values, in order to assign a role
... I think we could come up with a single set of terms
... there could be differences
... I don't think any of our motivations represent a target role very well
... and there may be some roles that don't make sense for an entire annotation
<shepazu> (I don't think targets should have roles, as far as I can tell… only bodies and the main annotation)
<Jacob> unless of course the point of the annotation is the juxtaposition of the targets
azaroth: shall we move on to the next option?
<Jacob> then each target definitely plays a different role in the annotation
Scenario 1. Option 3. https://www.w3.org/annotation/wiki/Expressing_Role_in_Multi-Body_Annotations#Role_Attached_to_EmbeddedContent_or_SpecificResource
<Jacob> +1
<azaroth> +0.5
<ivan> -0
<ivan> -0.5
<TimCole> +1
<shepazu> +0.5, I think?
<chrisbirk> -.5
+0 (would love to listen first ;) )
<Kyrce> +0
Role Attached to EmbeddedContent or SpecificResource
ivan: in one case you can use value and not just source
... in the previously one I said +0.9999 because there are some tweaks
... like allowing the value property
... I don't see any major reason for adding the types
... for RDF adding the types is fine
... but for JSON people it's just noise
azaroth: if we removed the types from this example, would that make it +1?
ivan: yes, but then it's back to the previous option
... and yes, would be a +1
<chrisbirk> sorry
<chrisbirk> I'll post here
<chrisbirk> From a JSON person's point of view, I would still have to loop through every body to get to the one I'm trying to access
azaroth: the difference between this one and the last one, is that the previous one is inside `source`
... but here, it's directly within the body object
... you would have to loop through them to find the one you want
ivan: shepazu the previous one matches your proposal
<chrisbirk> thanks bigbluehat. I'm more concerned with the performance side than ease of implementation
<TimCole> -1
<Jacob> Yeah, I was taking this a straw pole to assess which way folks are leaning.
TimCole: when I think of simpler, I'm thinking about interoperability
... for chrisbirk example, looping through all those to see if they have possible sub-properties
... whereas the other way around, I can loop through all the things that have `hasBody`
<Jacob> also -1 for the sub-property solution
azaroth: to be clear, you jumped on to the next option :)
<azaroth> -1
<ivan> -1
<chrisbirk> +1
Scenario 1. Option 4. https://www.w3.org/annotation/wiki/Expressing_Role_in_Multi-Body_Annotations#Role_as_Subproperty_of_hasBody.2FhasTarget
-1
Role as Subproperty of hasBody/hasTarget
<Jacob> Isn't there also a risk that we just keep developing new sub-properties forever?
Scenario 1. Option 5. https://www.w3.org/annotation/wiki/Expressing_Role_in_Multi-Body_Annotations#Role_as_Class.2FTyped_Bodies_and_Targets
<azaroth> -1
<Jacob> -1
<ivan> 0
Role as Class/Typed Bodies and Targets
<TimCole> -1
-1
<Jacob> I am with Rob
azaroth: this prevents reuse of a body having multiple types
<chrisbirk> -1
azaroth: it would be SemanticTag and any other thing it was assigned
<shepazu> (those are 2 different annotations… I don't see why it matters if 2 different annotations contradict each other)
ivan: it's essentially the same as assigning a role
... there seems no difference; and the semantic problem is not there...actually
... instead of role...it says type
<azaroth> Apologies for the mischaracterization
TimCole: the only difference is that you're typing the node
... rather than assigning it a role
... we did go through a discussion about assigning a type
... there is a difference in the RDF world
... basically type gets used for lots of different things
... it's fundamentally different than saying "this is text"
... we found type getting overloaded
<azaroth> I'm instead -0.5, due to Tim's comments, plus having to duplicate Motivations into classes
ivan: I don't think we disagree
... the difference with my vote earlier is precisely what you said
... the role's are cleaer
<shepazu> (I'd like to see a wiki page that describes the difference between role and motivation)
TimCole: yeah. I just think the type usage is not as clear as the other
<ivan> Dougs proposal: http://www.w3.org/mid/55D3BF3B.1070803@w3.org
<TimCole> The motivation for the annotation is to book mark a target; within the context of that motivation, one body comments and one body describes
ivan: what's the additional restriction here?
TimCole: I've not yet convinced myself that it'll be possible to know the type of the body
... but we allow role on both embeddedcontent and specificresource
... I'm not sure I'll always know which is which
... but assuming I do, then that issue goes away
... then the only other concern is that we may be encouraging roles on things that don't necessarily need roles
azaroth: there are 6 changes that would characterize shepazu's proposal
<azaroth> 1. Create a new predicate hasRole, with JSON-LD mapping of 'role'
<azaroth> 2. SHOULD use Specific Resource to carry roles
<azaroth> 3. Create a new subclass of EmbeddedContent, EmbeddedTextualBody
<azaroth> 4. ETB MAY have hasRole
<azaroth> 5. Create a new predicate "oa:text" to replace rdf:value, JSON-LD mapping of 'text'
<azaroth> 6. Rename hasSource to hasContent, with JSON-LD mapping of 'content'
<shepazu> 7. Remove types when not necessary
<Jacob> can you clarify the difference between source and content?
<shepazu> ( Jacob, I think it's just a name change )
azaroth: we create oa:text to further avoid types...making it easier to show that it's an embedded representation
... rename hasSource to hasContent because it's a clearer name
TimCole: my one concern is #6
<Jacob> This seems weird to me for selectors...but it might be because I'm used to thinking about content as the abstract stuff that's expressed by some text...
TimCole: we've tried to avoid invalidating existing implementations of the OA model
... is there a way we could deprecate `hasSource`
azaroth: the consequences of this change are going to be pretty drastic actually
<shepazu> https://www.w3.org/annotation/wiki/JSON_Vocabulary has a long list of changes
azaroth: the Tag and SemanticTag classes would no longer be needed
TimCole: just thinking about existing systems...I guess they just have to go back and update their data
<ivan> Ivan's iteration on Doug's proposal: http://www.w3.org/mid/37C51F52-B151-45C0-AE13-AFDC988639DA@w3.org
TimCole: it just seems like `hasSource` to `hasContent` is a small change will debatable value
<azaroth> 6b. Map hasSource to "content" in the JSON-LD mapping
ivan: in my proposal I tried to explore other variations
... it would have changes on the model
... and it would break backwards compatibility with the OA model
<shepazu> (I won't insist on the name change, but I think many things are going to change, so as long as we're doing that, we could do name changes)
<TimCole> +1 to 6b - content mapped to hasSource in @context.
ivan: I think my proposal would get use closer to the JSON view of the world...without sacrificing too much
... we can state that text is plain text, but position it so it can have roles, other properties, etc.
... we don't then have all these type heirarchies
... it becomes the only structure we have
... the only way to address an external resource is using the source property
... and then build from there
... it is a bit more complicated from an RDF point of view
... but for the JSON point of view, it seems simpler
... and it's still perfectly OK for the Linked Data perspective
<azaroth> +1 to putting complexity in the RDF side if it makes the JSON side easier
ivan: my preference would be too lean complexity toward the RDF developers
<shepazu> (I think we still need to address Chris and Bill's "iterating bodies/roles" issue, and I don't know how)
azaroth: ivan I'd be -0.5 because I think we'd end up with lots of errors
<azaroth> "body" : {
<azaroth> "source" : {
<azaroth> "id": "http://example.com/image.png",
<azaroth> "type": "Image"
<azaroth> }
<azaroth> }
azaroth: if you wanted to say that `source` was an image, then it would have to be an object
ivan: this is how the JSON world works. either the value is a string, or it's something that has properties
... this is always what I saw when people use JSON
... having the SpecificResource distinction also doesn't matter much anymore
<shepazu> +1
TimCole: when this has come up before, there has been some pushback
... that they really like the simplicity of thinking as the Tag directly as the body
ivan: I understand. Yes, it is more complicated on the RDF side, and I am absolutely with you on this.
<azaroth> +1 to only on SpecificResource and always requiring SpecificResource
<shepazu> ( Kyrce, I want to make sure Pearson is comfortable, so let's find a time when several of us can get together and we'll sync up )
ivan: the point is, that we will have to make it complicated on one side or the other
... putting the complications on the RDF side...SPARQL, etc, can handle it
<azaroth> eg the range of hasBody and hasTarget is oa:SpecificResource or literal
ivan: they dream with graphs anyway
<azaroth> not resource or literal
TimCole: I'm not sure that the complexity is necessary
... is this a way to avoid putting the type on?
ivan: yes, there's that, but I'm trying to follow the traditional JSON view of the world
... this is what shepazu did, he started from the JSON view
... I was surprised and pleased to see his mails this morning and seeing convergence happening
<shepazu> (this has always been my goal)
TimCole: I agree. I think the other one does to
... the sparql query can be done, but that there was some performance cost
... it does seem it will make it simpler for a JSON developer
... and if we don't use framing, because it's not complete yet, then I think this is good
azaroth: top of the hour, and I'm needed on another call
... I'll write up the two options
... essentially what Ivan has proposed and we've agreed to on this call
... we can try to discuss further on the list
... then issue a call for consensus
... if we can come to consensus, great! if not, we can present some options
... and then do a call to select a winner
ivan: can you do this on the wiki first, so we can avoid gigantic mail threads?
<shepazu> ( chrisbirk, can you guys make a proposal for solving your iteration issue? )
azaroth: anyone averse to doing this in a GitHub page using ReSpec
<TimCole> github okay with me.
+1 to doing this in ReSpec
<chrisbirk> shepazu talking with bigbluehat after this call
<ivan> +12
<Jacob> +1 for GitHub
<ivan> trackbot, end telcon
