Web Annotation Working Group Teleconference

<trackbot> Date: 12 August 2015

Agenda Review, Scribe Selection, Announcements

<tbdinesh> i cant hear anyone

<fjh> ScribeNick: Jacob

Minutes Approval

<fjh> proposed RESOLUTION: Minutes from 5 August approved, http://www.w3.org/2015/08/05-annotation-minutes.html

RESOLUTION: Minutes from 5 August approved, http://www.w3.org/2015/08/05-annotation-minutes.html

Planning updates

fjh: need to think about the deliverables

do we have them?

<fjh> Deliverable review and status - Rangefinder, HTML Serialization, Client API

scribe: plan for tpac

<fjh> TPAC planning

scribe: need to register, answer questionnaire (will be very helpful), decide on workplan, ensure that enough people are present

TimCole: interested in connecting to tpac morning sessions if there are topics where additional participation is needed

<fjh> TPAC registration - required - https://www.w3.org/2002/09/wbs/35125/TPAC2015/

<fjh> WG questionnare https://www.w3.org/2002/09/wbs/73180/annotation-tpac_2015/

fjh: questionnaire is to help us determine who needs to call in, calling in will be difficult

<fjh> https://www.w3.org/2002/09/wbs/73180/annotation-tpac_2015/results

Protocol

fjh: client api, reminder that it needs to be figured out

<fjh> container clarification resolved? - https://lists.w3.org/Archives/Public/public-annotation/2015Jul/0238.html

fjh: 1) container issue, 2) other issues, 3) clarify web architecture issue as note in draft, 4) publish updated WD using lightweight publishing, 5) share with TAG

bigbluehat: rdf representation, encodings should not be labeled as non-rdf but other than that everything looks fine
...

shouldn't matter if we call out non-rdf resources, essentially optional, client ... shouldn't make additional assumptions

TimCole: bringing up another protocol issue, but want to make sure there are no other container issues

<fjh> Group agrees to close container issue

TimCole: looking at 4.1 of the model document, needs to move to the protocol document

azaroth: for derefencing things, 6th paragraph of 4.1 making protocol requirements in the model

TimCole: don't forget to move that to the protocol doc

fjh: need to put a note in the document to indicate what is being looked for in review

azaroth: note that we inherit additional requirements in the doc

fjh: to-edit based on Tim's suggestion, then update of working draft, then can share it

ivan: does this mean that Erik's issue is off the table?

azaroth: may have complaints about json-ld with context but majority of Eric's issue has been shifted from us over to LDP

<fjh> no, we think we have simplified impact of his issue on our spec by framing it

<fjh> suggest we try to recast issue in specific edit terms rather than general terms.

azaroth: can ping Erik to have him look at the working draft again (to verify that his issue has been sufficiently addressed)

<fjh> getting view from TAG is valuable, if only to get buy-in

shepazu: still want to hear what TAG has to say about what we have earlier rather than later

JSON-LD Context

<fjh> https://lists.w3.org/Archives/Public/public-annotation/2015Aug/0050.html

<fjh> a) make change proposed by Tim https://lists.w3.org/Archives/Public/public-annotation/2015Aug/0064.html

<fjh> b) by Ivan https://lists.w3.org/Archives/Public/public-annotation/2015Aug/0075.html

azaroth: seems like a good idea, actions on Rob to ping Erik and get the edits done
... moving onto the json-ld context, relationships were identifiers but not such that they resolve against the context
... e.g., if one sends a ns'd query that works but just bookmarking doesn't
... classes seem to be magic in the playground, so can get @type

<fjh> "motivation": {"@type":"@vocab", "@id" : "oa:motivatedBy"}

azaroth: Tim found a workaround '@type: @context' that does get @context

TimCole: need to think about whether or not this makes it harder for communities to extend the list of motivations, might be easier for those who understand rdf
... but harder for those who don't, but might not be able to help them anyway
... can use @vocab to pick up vocab terms with @type

azaroth: won't work across communities, but not a solvable problem

TimCole: json-ld spec (sec. 6.5) talks about type coercion -- @id and @type are specially defined
... when using @id then the subject is assumed to be an IRI whereas the subject of @type assumes a term that may appear in @context

<azaroth> q

<azaroth> ?

Ivan: can forget about all of the namespacing with this solution (i.e., relying on the json-ld parser)

azaroth: Ivan's question about changing @type & @id to something without '@'

Ivan: it's hacking the json-ld but it works, if we add it to the context then we can use simpler strings for serializing, which is simpler
... can use a good string for the id, e.g., changing @id to id: or url:

<shepazu> [I like this]

<bigbluehat> @id's will still show up throughout the document, yes? if we're not using (or not preferring) blank nodes for body, etc.

Ivan: in practice, only place in our json-ld that '@' would be used is in the '@context' and even that can be subsumed[?] into the header

<Zakim> TimCole, you wanted to ask about whether url is best label

<azaroth> +1 to not url

TimCole: concern about 'url', times when blank nodes need to be referenced from other places in the graph, so don't want folks to think that 'url:' must be filled with a url rather than a blank node

<azaroth> +1 to id :)

Ivan: fine with using id, don't want to prevent people from using urns, etc.

+1 from me

<Zakim> azaroth, you wanted to note @value

azaroth: one other '@' not being used in the current context, but might want to sub a string for '@value'
... not sure that we can get rid of '@value:string ; @type:string'

Ivan: is an edge case?

azaroth: yes, should treat it as a string in [most cases?], just wanted to point out that it could come up

bigbluehat: only concern is name collision with ids from databases, in practice json dbs will already use id and type internally, don't mind '@' but some people are wierded out by it, is an edge case, seems fine either way
... do we have many other types?
... if we map 'type' to '@type', it carries through

<bigbluehat> {"@id": "http://example.org/...uuid...", "_id": "...uuid..."}

azaroth: yes, should see what happens, but it is an edge case

<azaroth> And that it enables annotation.id in javascript, rather than requiring annotation['@id']

bigbluehat: collision scenario might be with the couch db example [above in the transcript], might not be resolvable

<bigbluehat> in CouchDB, MongoDB, Vue.js, etc, it's not a problem as they use "_id" so...no issues there.

<bigbluehat> but others may lay claim to "id" and "type"...but...who knows...

ivan: found a nice trick for getting rid of '@' but, can come back and choose symbols different from 'type' and 'id' if we find that there are collisions with dbs

<PaoloCiccarese> I might be wrong but both mongo and elastic use _id

<PaoloCiccarese> not id

<azaroth> RESOLUTION: Use id and type in the annotation context in place of @id and @type to make the serialization more friendly to javascript developers

fjh: will also capture the previous agreement as well

azaroth: further note, if json-ld serializer sees '@id' and '@type' it won't be wrong

RESOLUTION: Use id and type in the annotation context in place of @id and @type to make the serialization more friendly to javascript developers

<bigbluehat> +1 to PaoloCiccarese's concern

PaoloCiccarese: if reading json-ld by hand without using a parser, would need to map all of these variances

ivan: yes, that's technically right, but in practice, is it best to describe all of our documents with all of the examples using id and type, understand that its an issue, but is it a major issue

PaoloCiccarese: think we might have to mention the issue
... if the client is a strict javascript client, doesn't use json-ld libraries, uses framing, so it doesn't do much parsing, the problem is
... if it gets annos from another client, it will need to internally translate it to conform with the no '@id', etc.
... not sure if hiding it is the right thing to do, will become undocumented

<Zakim> azaroth, you wanted to suggest noting in the context appendix

PaoloCiccarese: if everyone agrees then isn't an issue but someone might use it in the future and the parser may be unaware

azaroth: suggest that we might (because agree with Paolo), remove the context from the appendix and reference it so that we don't have to change the model doc if we find bugs in the context

<PaoloCiccarese> +1

azaroth: so it will be documented but only in a place where people who care about context can see it

TimCole: suggest that applications SHOULD use 'id' and 'type' so that it is less of a problem

azaroth: will make an issue in github that the change should be made to the model

Data Model

<fjh> Multiple body

<fjh> solution : https://lists.w3.org/Archives/Public/public-annotation/2015Aug/0048.html (Tim, Paolo)

<fjh> and https://lists.w3.org/Archives/Public/public-annotation/2015Aug/0062.html (Tim)

azaroth: solution for roles, have a set of little objects linking resources to roles
... upshot is, all of the bodies need to have at least a blank node id if they are to have a role, makes the change very contained

<fjh> wiki link from Tim - https://www.w3.org/annotation/wiki/Expressing_Role_in_Multi-Body_Annotations

TimCole: in working through the issues, one thing is if you have a text body, then you must move to embedded content
... right now we have a 'SHOULD' to add a dctype to the embedded content, might want to move to 'MAY' so that it won't be so verbose

<azaroth> +1 to using role to describe tags

TimCole: alternately we've been using tag / semantic tag to link the roles to tag bodies, could replicate this pattern for other bodies

<PaoloCiccarese> +1 to the semantic tags

TimCole: or do we want to remove the tag / semantic tag typing in favor of having roles?
... need to consider these things

<azaroth> and -1 to reducing SHOULD to MAY

shepazu: the syntax is even obtuse than other syntax that felt that other people would find hard to use
... hardcoding in a semantic web thing, no one will understand this (unless they are a semantic web person)

<Zakim> azaroth, you wanted to +1 roles and remove tags

shepazu: increasingly disturbed by the hoops that must be jumped through to accomplish this, wanted to make things simpler but things are only getting more complex

azaroth: either way, if its a specific resource with a role or a specific role, +1 to using roles to express this rather than separate types and -1 to reducing should to may

PaoloCiccarese: agree on using roles
... looks like there is a constant pressure between json method and json-ld method
... the json people would just use comment rather than role
... wondering if we can have a json format, distinct from json-ld
... can we have a process for moving from json-ld to json so that the developer doesn't have to deal with it
... constraints, etc. are not a natural part of json, so it makes json implementations more difficult

<fjh> Paolo thanks for intelligent question based on end-user communities

PaoloCiccarese: downside, would need a complex bit to do this walk between them

shepazu: thought that we should have a data model that describes the parts of the annotation and separate serializations
... but would make the data model something that non-semweb folks something that they can easily adopt
... also believe we need an html serialization, which will look different from either of the json serializations

<fjh> question regarding serialization round-tripping as requirement - no data loss...

<bigbluehat> +1 to fjh's concern

ivan: we need to explore this issue, not sure about best forward, would need to give a very precise description of a processor,

<fjh> dare I say, direction sounds like XML InfoSet ?

<azaroth> For reference, the JSON-LD mapping: http://www.w3.org/TR/json-ld-api/

<bigbluehat> along with an ever widening list of serializations for "comment", "highlight", etc...

<Zakim> azaroth, you wanted to -1 two json serializations

ivan: worried about the complications that will be required, worried that the complication of the processor will be significant but we should try

azaroth: having non-interoperable json serializations balkanizes the community

<bigbluehat> can we invite James Snell to fill us in on Social's work with this same issue?

<bigbluehat> azaroth: ^^

azaroth: out of time, agenda item for next week, continue discussion on mailing list

<bigbluehat> http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams-core/index.html

azaroth: social web group ran into a similar problem of semweb vs web developer communities

<bigbluehat> +1 to list first

Adjourn

<ivan> trackbot, end telcon