See also: IRC log
<trackbot> Date: 21 January 2015
<azaroth> Thanks Frederick!
\me ...agenda is minutes, use cases (Paolo), protocol, linking, data model
<fjh> https://lists.w3.org/Archives/Public/public-annotation/2015Jan/0040.html
<fjh> RESOLUTION: 17th December 2014 minutes approved: http://www.w3.org/2014/12/03-annotation-minutes.html
<fjh> announcement, please don’t put inappropriate conference notices on list https://lists.w3.org/Archives/Public/public-annotation/2015Jan/0035.html
<fjh> announcement - we can annotate the spec again, thanks to the team https://lists.w3.org/Archives/Public/public-annotation/2015Jan/0040.html
<fjh> - Face to face is Apr 22— we’re green to go.
<fjh> - W3C should handle all logistics and planning for that except for the reservation of the room and lunch, which will be provided. I can discuss offline w/ the chairs/staff.
<fjh> - I Annotate is Apr 23-24 (hack days 25-26) please register if you intend to attend. http://iannotate.org/2015
<fjh> - If you’d like to stay at the hotel we’ve blocked out, please let me know directly.
<fjh> - If you need travel support (i.e. cannot attend without it), ask now.
rob: face-to-face is april 22nd
<fjh> another announcement, looking for help with updating wikipedia article https://lists.w3.org/Archives/Public/public-annotation/2015Jan/0036.html
rob: tried to get boston but timing didn't
work out, so it will be taking place in San Francisco
... it will be followed by iAnnotate on the 23rd and 24th
... with the 25th and 26th as hack days
... suggest making a wiki page for rsvps
... please rsvp, there may be some funding to support travel to the
face-to-face
... ldp group, thinking about a workshop, looking for a time and space
... suggested that it could occur at iAnnotate
... would fall on the 21st, the tuesday before the face-to-face
fjh: need to be clear w/regards to the confirmation date
<fjh> +1 to wbs poll
doug: administrivia - normally use the wps
-- w3 polling system to manage the rsvp and attendance notes
... could set one up, would help highlight who will be in attendance
<csillag> zakim: +??P33 is me
<azaroth> +1 to poll w/ extra questions
fjh: could also use this to indicate attendance of the workshop and iannotate
fjh: moving to use cases
<fjh> Link: https://www.w3.org/annotation/wiki/Use_Cases
Paolo: only one set of use cases that is not
yet added to the wiki
... need further clarification, Jacob should rewrite to conform to
existing cases in the wiki
<azaroth> +1 to collecting everything and sorting/clarifying it at the end
Jacob: I should log into the wiki and add them there?
paoloC: That would be great, the language is a bit specific to the field, so I didn't follow exactly the use cases
Jacob: I can do that this afternoon
paoloC: If you want to send me a note that you've added them, I'll check them out right away
<Jacob> ... agreement with regards overall, seems to be is to collect every possible use case and sort them later
paoloC: unless I've missed some that's all.
I have some ready to add from my work, including structured annotation
... which we haven't explored that much
<scribe> ScribeNick: Jacob
PaoloC: some implementations being done on
top of a triple store
... recalls ivan saying that JSON LD Framing implementations are not
standard
<fjh> issue noted by Paolo - client should not need to understand graph, hence framing needed
PaoloC: is this a protocol use case?
Rob: not protocol
... wouldn't have a remote client with a particular frame
... not up on all the details yet as not standardized yet
Paolo: have three use cases, bakcend -- does
not matter if framed as it will interpret as rdf anyway
... but in the case of actual clients it matters, and so it (e.g.,
Annotopia) prefers framing in order to interpret the message without
rebuilding the graph
<fjh> do we need to add this as an issue or use case requirement on clients?
Paolo: no idea how to make this work without framing
fjh: should this be a use case requirement?
... seems similar to html issues, how do we capture this issue?
Rob: ... clarify the relationship with rdf,
not a problem in general terms but don't want to give impression that it
is required(?)
... talk about graphs were appropriate and don't when not
Paolo: problem will also come up for
structured bodies
... because the return a graph, an rdf concept, in this case, framing
may also come into play unless clients are making multiple calls to
retrueve both annotation and graph
<fjh> can someone please put a link in the chat about framing
<TimCole> http://json-ld.org/spec/latest/json-ld-framing/
Ivan: only 3 or 4 folks in the group are working with json ld framing; what is framing going to do for the developer and not worry about details of triple stores
fjh: should record the issue at high-level terms
ivan: exactly
<fjh> and use case / client needs, requirements
paolo: so should have a templating mechanism?
<fjh> +1
<azaroth> +1
<fjh> you can give pointers in addition to high level description
<azaroth> +1 to shepazu re implementation agnosticism
doug: should outline the specific outcomes
and needs, shouldn't avoid building solutions that deal directly with
rdf but also shouldn't focus solely on such solutions
... no reason to avoid rdf but not use it as the only way to discuss
issues
fjh: should document the issue
<fjh> Dan’s email re disscussion is well worth reviewing in my opinion https://lists.w3.org/Archives/Public/public-annotation/2015Jan/0013.html
fjh: different topic; seems like the use
case discussions are beginning to get philosophical
... cannot anticipate how the standard will be used in every case
... getting confused why we are going into so much detail
rob: regarding the philosophical discussion,
my understanding, whether or not some use cases count as annotations
... very much in favor at this stage to collect everything and sort them
once we have the full set of use cases and requirements
paolo: also read some discussions on
bibframe; annotation is different things for different people
... comes down to how the implementations are being build
... also fluid, sometimes moves from being an annotation to content
<azaroth> +1
<fjh> +1
paolo: understand that we would like a precise definition but it is better for now to move forward with the existing def
fjh: moving to deep linking
doug: deep linking - being talked about in
mobile circles
... somewhat related to annotation
<fjh> http://www.w3.org/2001/tag/doc/deeplinking.html
doug: lawsuits regarding if links to
particular pages and states in sites and apps is legal
... used to mean linking into specific content but now means to evoke
particular states in an app
<fjh> doug: deep linking now means app can access data in another app on that device
doug: can click a link for a mapping app to go to particular state in that mapping app
<fjh> s/doug.*//
<fjh> forget the tag link, this is different meaning of deep linking
<fjh> is there a link with a description of this
doug: will send a message to mailing list
about this topic
... certain degree of interest with regards to our robust anchoring
... possible workshop around deep linking
... talked to urx and quick(something)
... w3c is interested because of the idea of having closer ties to
mobile / web apps
... will keep the group apprised of what is going on
rob: clarification - deep linking focused on what is displayed rather than the target of an annotation?
<Zakim> fjh, you wanted to ask if this is native app specific or web browser applicable
doug: both groups need the ability to
address content in similar ways
... it's an addressing issue
<azaroth> azaroth: Need to address content in applications, rather than the state of a running application (mobile or not)?
fjh: why is this a concern?
doug: cannot send someone to a particular
part of a document because discreet linking is lacking when there are no
ids
... while the web is good at linking, apps do not and that is the
problem being explored
... example: someone texts a link to some content in a document,
question is what should that link do; ideally it opens the exact page
that person 1 is referencing
<ivan> +1
doug: how do you reference something local to someone else's device?
<ivan> The EPUB-WEB white paper might show where the issues may be for DPUB that Doug was referring to: http://w3c.github.io/epubweb/
rob: this would be good to have a write-up of; certainly good to be aware of
<fjh> doug, thanks for sharing this - a mail to the list would be very helpful
rob: we should work with them if we can but we should beware of scope creep
doug: no one at w3 currently working on this
... possibility of a workshop
... don't want two different solutions
... for linking into content
<fjh> ivan, thanks for link
ivan: epub also looking at this issue
... moving towards an environment where content is sometimes offline and
sometimes online
... want the annotation to persist regardless of connectivity
<fjh> desire - seamless use of annotations when moving online and offline
<fjh> Link: http://lists.w3.org/Archives/Public/public-annotation/2014Dec/0062.html
rob: using ldp to (something) transactions
<shepazu> (note that the TAG document on deeplinking http://www.w3.org/2001/tag/doc/deeplinking.html is not the same thing as deeplinking as discussed today)
rob: using ldp for basic GET retrieval and
Activity Streams for the notifications
... would anyone be interested in writing up a straw man set of
requirements
<TimCole> +1 to hearing more about this next week.
<fjh> rob will create draft, seeking help
rob: happy to talk about this more next week
<fjh> I am interested in helping on this
<fjh> rob: can discuss next week
rob: any other concrete examples that we should be looking at? would like to discuss further next week
fjh: plan on these as agenda items for next week
<shepazu> WBS poll: https://www.w3.org/2002/09/wbs/73180/annotation-q1_2015/
fjh: fjh not on next week's call, rob will be chairing with ivan's assistance
<tbdinesh> ??P33 is likely me
<fjh> in two weeks Ivan will chair
note: ivan chairing the week after not assisting next week
<shepazu> https://www.w3.org/2002/09/wbs/73180/annotation-q1_2015/
<azaroth> Thanks Doug!
doug: face-to-face poll is up, will add ldp write-up to it as soon as available
fjh: adjourning