See also: IRC log
<trackbot> Date: 12 August 2015
<tbdinesh> i cant hear anyone
<fjh> ScribeNick: Jacob
<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
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
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
<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
<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
<ivan> trackbot, end telcon