See also: IRC log
<trackbot> Date: 03 December 2014
<fjh> s;Agenda:.*;Agenda: http://lists.w3.org/Archives/Public/public-annotation/2014Dec/0007.html;
<fjh> Agenda: http://lists.w3.org/Archives/Public/public-annotation/2014Dec/0007.html
<bigbluehat> fjh: can we include the call number + extension as a tel: URL in the agenda mails? :) would be handy!
<bigbluehat> what's the command to associate # + name?
<bigbluehat> thanks!
<bigbluehat> bigbluehat: == Benjamin Young
<bigbluehat> no worries! :)
<fjh> mapping number to handle automatically https://www.w3.org/1998/12/bridge/info/name.php3
<MGU> Sorry, y english is not good enough :-(
<ivan> scribenick: TimCole
<fjh> revised agenda http://lists.w3.org/Archives/Public/public-annotation/2014Dec/0007.html
fjh: reviewed the agenda
<fjh> updated scribe list https://www.w3.org/annotation/wiki/Scribe_List
<fjh> proposed RESOLUTION: 19 November 2014 minutes approved: http://www.w3.org/2014/11/19-annotation-minutes.html
<ivan> +1
shepazu: other groups don't do minutes approval on the call
fjh: would prefer to keep doing it on the call
RESOLUTION: 19 November 2014 minutes approved: http://www.w3.org/2014/11/19-annotation-minutes.html
<fjh> Call for implementations and participation, see http://lists.w3.org/Archives/Public/public-annotation/2014Nov/0137.html
<fjh> community group, http://lists.w3.org/Archives/Public/public-annotation/2014Nov/0130.html
fjh: Doug sent out email requesting
implementation ideas / details
... also a message went to CG
shepazu: we want to be able to annotate our
(W3C) own specs
... we want to start with Annotator
... we want to use other tools as they come forward
... discussion about which tool should not be something on which we
spend time
... so we formed a spec annotation CG
... if you are interested in the software aspects (as distinct from
standardization), should join the CG
... so please offer other tools, multiple implementations, ...
fjh: One thing we need to know when we can start annotating, and if there are instructions for doing it
shepazu: we hope to be ready by Friday
... this will be done on Webplatform.org
... when you select something you will see the side bar
... annotate in using the sidebar (after logging in).
fjh: any questions?
azaroth: to clarify this will be a copy on webplatform.org rather than the master on w3c
shepazu: we will encourage editor drafts on webplatform.org, but will also be able to annotate on w3c.org
<fjh> Call for Consensus (CfC) to publish FPWD of Data Model Completed, http://lists.w3.org/Archives/Public/public-annotation/2014Dec/0000.html
<fjh> Transition request sent, https://lists.w3.org/Archives/Member/chairs/2014OctDec/0182.html (member only)
fjh: no objections to publishing FPWD
... we want to get this published before the moritorium
<fjh> oa namespace, JSON-LD context http://lists.w3.org/Archives/Public/public-annotation/2014Dec/0001.html
fjh: perhaps we can just change the landing page to reflect that we are now managing the context
azaroth: we can update the context URI
separately from the namespace
... this would leave the previous context URI for the CG and would put
the WG context at new URI
ivan: we can work out the details by email
<fjh> +1 to rob sending email to list with details
ivan: Rob will write down his idea in detail and he and Ivan will make this happen
<azaroth> ACTION: azaroth and ivan to discuss the details of migration offline [recorded in http://www.w3.org/2014/12/03-annotation-minutes.html#action01]
<trackbot> Created ACTION-2 - And ivan to discuss the details of migration offline [on Robert Sanderson - due 2014-12-10].
fjh: do we have anything new?
shepazu: there is a lot to talk about.
... how do we wan to approach this?
... people on the call who want to talk about the topic
... if not, Doug will introduce it on the email list
fjh: Maybe an email to the list and then a discussion on a call might be best.
shepazu: wondering if people on the call today that have an interest in robust anchoring
<ivan> +1
<fjh> interested, not sure whether off call preparation is needed
<fjh> believe so
<azaroth> +1 to pre-call prep
<fjh> +1 to having concrete proposal to work from
paoloC: best to introduce and raise concrete examples to help frame productive discussion
shepazu: volunteers to put together an initial draft for discussion
ivan: would like to hear more about what
implementations do now
... what are the approaches, experience, positive and negative
... experience is a good place to start
<fjh> ACTION: shepaz to provide robust anchoring architecture draft on list to give start [recorded in http://www.w3.org/2014/12/03-annotation-minutes.html#action02]
<trackbot> Error finding 'shepaz'. You can review and register nicknames at <http://www.w3.org/annotation/track/users>.
<fjh> ACTION: shepazu to provide robust anchoring architecture draft on list to give start [recorded in http://www.w3.org/2014/12/03-annotation-minutes.html#action03]
<trackbot> Created ACTION-3 - Provide robust anchoring architecture draft on list to give start [on Doug Schepers - due 2014-12-10].
azaroth: there are a large number of examples from CG and elsewhere to draw on
paoloC: would be happy to share experience
gleaned over several years
... we should be able to annotate HTML
... not easy to handle for several reasons
... for example the same document in different clients has different
byte count, etc.
... so we use prefix and suffix to what you are annotating
... prefix and suffix a certain number of characters
... if subsequent re-matching works, then all good
... if not, increase length of prefix and suffix
... works for some changes elsewhere in the document if these don't
change the prefix and suffix
... when match fails (because of document change) our client just shows
the annotation on the side (orphaned)
... the idea of prefix and suffix also works well for cross-format use
cases (annotate PDF, display in HTML)
<fjh> paoloC: handles dom processing to convert tags to strings as needed
paoloC: we have developed rules of thumb
over time
... as Web pages become more complex, and as CSS affects presentation,
so we try not to cross sections when calculating prefix and suffix
... sometimes may only be able to have a suffix
... these have been tuned on scientific papers, wikipedia, other content
that our users annotate
shepazu: questions - when trying to reanchor an annotation, do you change the context?
paoloC: did some experimentation a few years
ago
... first you tests right away
... then when you come back 6 months it no longer works
... you may be able to make a good guess, but often for scientific
papers not always a good idea
shepazu: poetry, lots of repetition, so you need to know which instance
<fjh> paoloC: issue is that same word might appear often in technical paper, so hard to anchor without more information
paoloC: even worse for legal documents
<fjh> shepazu: also music lyrics
paoloC: other tools use different approaches that may be better for such situations
shepazu: not clear about approaches that
work well for increasingly modern dynamic documents
... so not sure how much literature has dealt with these newer, very
dynamic documents
... if an annotation engine wants to say this annotation would be better
anchored with new anchors, do we still keep the old anchors?
paoloC: most of the problems last few years
have arisen trying to keep up, i.e., because of increasingly dynamic
documents
... because of all the javascript now being used by publishers - making
things harder
<fjh> are ads a problem?
paoloC: but sometimes you can get api access
to the base document
... not able to annotate flash
... technological challenge is great, things change
... re keeping track of new selectors, we have to be careful to track
provenance, e.g., we have to keep track of what was initially annotated.
<Zakim> fjh, you wanted to ask about rules of thumb documentation
<azaroth> +1 to the danger of changing selectors in some domains
paoloC: it can be dangerous to change exactly what was annotated and the original selectors
fjh: Paolo, do you have documentation we can share
paoloC: some documentation shared with hypothes.is previously
<fjh> paoloC: work with static docs, but javascript becomes a problem
paoloC: an example of changes is how images
are handled
... used to be a fixed size, now the image size changes when you mouse
over
... so the annotation client alters the behavior of the page so that the
image is always fixed size.
nickstenn: what comes to mind in listening
to this is how hard this is to do in general
... we need to keep in mind a number of considerations that haven't yet
been raised
... how do these approaches work in non-Western languages
... not convinced we know what we're doing well enough to standardize
fjh: we should continue this discussion on
the list, unless someone has a contribution now that we need to get
started
... we don't yet have a robust definition of robust anchoring, but we
understand that to make annotation work, we need to lay out the
landscape
<fjh> lets take this to the list
Dinesh: for example versioning control; I
anchor one version and that may be important
... that's all we can say at this point
<nickstenn> My position: we should focus on what support we need in APIs and model for robust anchoring, rather than talking about algorithms
<fjh> Call for use cases http://lists.w3.org/Archives/Public/public-annotation/2014Nov/0128.html
fjh: we have the call for use cases for Rob. We need to decide who else to send that call to.
<azaroth> +1 to broader sharing
<fjh> cross-format annotations http://lists.w3.org/Archives/Public/public-annotation/2014Dec/0005.html and http://lists.w3.org/Archives/Public/public-annotation/2014Dec/0006.html
fjh: we have from Paolo the cross-format use
case
... there were use cases from the dpub IG
paoloC: my point of raising cross-format use
case is to help us keep in mind interoperability
... what can be done whether what domeo does makes sense, is a good
starting point
<bigbluehat> the dpub use cases are all linked from the wiki (and tagged using azaroth's tags) at https://www.w3.org/annotation/wiki/Use_Cases#List
paoloC: Benjamin Young and I worked on setting up the use case page - use cases should include concrete examples and should be clear about what areas the use case impacts
<bigbluehat> sorry for the nit...there's a lot of us :-P
paoloC: the cross-format use cases raises
the possibility of annotating an identifier (that might not be a URI)
... for example annotating a doi or pii, i.e., a work that may have
multiple representations, each with their own URL/URI
... these identifiers are a shortcut for associating an annotation with
a work
fjh: we should take this to the list and help us figure out what the WG wants to focus on.
fjh: discovery is not explicitly in our charter, so we need to figure out if there's something meaningful that fits with us. Any quick thoughts?
<bigbluehat> agree with shepazu
shepazu: thinks discovery is part of the
REST API
... this is being discussed in parallel in the Social WG
<fjh> good to know, then we should start thinking about this more seriously
shepazu: so we should discuss and coordinate closely with Social WG
azaroth: agrees discovery is important to do
... but parts could be deferred until we have better and more use cases
to help us understand the scope appropriate for annotation
rayd: summarizing from his email - doesn't
want to impose a burden to deal with the full discovery
... but if we can define a mechanism for notification, i.e., the ability
to notify the owner of annotation target
... this would allow the owner of the target to take action as
appropriate
... provided 3 use cases
paoloC: volunteers to copy into the wiki
<Jacob> This sounds familiar. Is it worth looking into the 'expectation' use case again?
paoloC: will interact with rayd to make sure we don't mis-represent
shepazu: the diagram we've been using does cover notification - not explicit in the charter, but is something we have discussed before.
<fjh> proposed RESOLUTION: no teleconference 24 December or 31 December
shepazu: it may not be this WG that ultimately defines the discovery mechanism, but we need to be part of the process.
RESOLUTION: no teleconference 24 December or 31 December
fjh: defer decision on 17 Dec.
<fjh> Thanks everyone!
<ivan> trackbot, end telcon