See also: IRC log
<trackbot> Date: 29 April 2015
fjh: suggest we not approve minutes this week, wait until next week and give people time to review them.
<fjh> http://www.w3.org/2015/04/22-annotation-minutes.html
<fjh> F2F summary - https://lists.w3.org/Archives/Public/public-annotation/2015Apr/0157.html
fjh: sent message with summary of f2f. one
day meeting in conjunction with the iAnnotate conference. Looked at LDP
work because people had gone to the LDP f2f. much relates to what we are
doing
... update regarding social web which is a solid proposal based on LDP.
then talked about client API all linked from link in chat. Decided to
proceed with what Nick had done. Lower level js apis are appropriate
rather than trying to complicate.
<fjh> nick’s message on text offsets https://lists.w3.org/Archives/Public/public-annotation/2015Apr/0158.html
fjh: publishing: markup is best. RangeFinder API had some questions. Lots of algorithm choices doesn't necessarily help. Overall- check the minutes, all of this is there.
<fjh> I Annotate, see https://docs.google.com/document/d/1ML3u4hmCF2oeIFNG3To4L1NBjqWnYQ37vYJ5Y2eLUdY/view
fjh: iAnnotate. A lot of good stuff. There is a page with a summary.
<TimCole> https://rawgit.com/w3c/aria/master/aria/dpub.html#footnote
TimCole: so regarding the footnote issue. there was a call on Monday. as per HTML working group, holding off on footnote pending accessibility. Ancillary attributes and elements. We may want to look at that and the proposed area draft. Draft was published around April 20. This is current thinking.
<TimCole> raised potential footnote element in HTML during DPub IG call.
<TimCole> the sense is that adding this element to HTML is on hold (for various reasons)
<TimCole> one of them being that footnote is a role in WAI-ARIA and both DPub and HTML want to see what happens with that
<Shepazu> also had a chat with Mike Smith for html working group. He indicated that he did not think the browser vendors would not be amenable to note element, or the like. There was a lot of discussion around footnotes and pullquotes etc when aside was discussed. There are a lot of people in the HTML community who look at <article> or <section> and say that they are not needed in retrospect and that they do not offer functionality only encode something semantic that can be done otherwise. Asked if there was a way to encode a note element. He suspected that there would be fairly strong resistance to this unless it was made more useful.
<TimCole> we may want to look at how this is proposed for implementation in the Digital Publishing WAI-ARIA Module April 20 draft
<fjh> ivan: fundamental discussions between formatting & prototocols wg and digital publishing community
Ivan: referring back to the ARIA reference. Discussion around this. Cannot say when document will move on and how. No technical details here at the moment. We should not rely on it for this working group.
<Zakim> azaroth, you wanted to ask about ideas on the way forward
Azaroth: Ways forward with HTML based for innovations. Should we try to work with the ARIA group and get a role attribute value defined rather than going up to HTML level. or microformats or what
<dauwhe> Hixie on footnotes in HTML: https://lists.w3.org/Archives/Public/public-whatwg-archive/2008Apr/0198.html
Ivan: So does come back to the discussion we
had with publishing community. The publishing community has had the
notion of structural semantics. They need a way to implement. That's
something that community needs. Close to a hundred different notions for
the educational market
... The current work roles to use the ARIA role…. should role attribute
only be used for accessibility? or for something larger (eg structurual
semantics). If we don't use it then they have to define something new.
If this happens, the notions that the digital publishing groups may work
for these as well as Rob said. But I have no idea what direction they
will take. We should wait.
... Driven by accessibility not by browser vendors exclusively. All
together.
<paoloC> http://www.w3.org/community/openannotation/wiki/RDFa
paoloC: I don't know about accessibility. We have been experimenting with RDFa. It's not easy. It's a bit ugly at times. Worked with Ivan. Not knowing what is going on in the next six months with other groups, we should keep on top of RDFa and the microdata—and how it can be formalized. Also a backup no matter what happens in other groups. Why not have this also?
<azaroth> +1 to Paolo ; remaining informed and keeping options open is good
<shepazu> suggest concrete ways in which <note> would differ from <aside>, describe functional mechanisms rather than just markup (such as accessibility and navigation), review all decisions about aside and footnotes, make sure to coordinate with WAI and with CSS WG about rendering
<shepazu> I've always thought we should express it as RDFa. The question is can we also use plain HTML. I typed up a few concrete ways in which note would differ from aside. Navigation challenge: from a place in the doc to the footnote back to the originating instance. It's a functional requirement that's hard to fulfill today. We should review all the requirements around <aside> and footnotes. Coordinate with CSS working group and accessibility folks about their needs. CSS working group has been working on the rendering of this problem. We should coordinate with Dave Kramer who is working on this as well. I think there are functional differences and differences in the API. It's not interesting if we only just propose markup. We need different UI.
<fjh> +1 to paolo
<Zakim> azaroth, you wanted to ask about accessibility of annotations in aria
azaroth: Ivan i wanted to ask about the accessibility issue. Client displays annotations in the sidebar. How does a screen reader handle this?
Ivan: Very similar to the other cases that
we have right now in pub and accessibility group. I think the answer is:
similar to HTML. Requirements can be handled by ARIA. Introducing a
separate value should not be allowed. From accessibility POV there is no
difference. Fundamental questions about the role of the attribute. Is it
just for accessiiblity? or is it for other kind of "semantics" There are
two different views.
... ARIA role as a much more general feature for accessibility for
adding semantics to HTML code. People use classes for, which can clash.
I"m not sure of the direction.
Role is not special behavior. Role as a signal to user agents, usually screen readers that they should pay attention, not to do something specific. Role is not the way to go for behavior.
<tbdinesh> +1 to shepazu (although annotator role might make sense)
fjh: markup should be specific to navigation. Can you explain what you meant by being able to "act"
shepazu: obvious example is hyperlink. nav
element doesn't do anything just says that this is navigation. Similarly
section, article. Details does something. a couple of different types of
behavior. examples: wikipedia. when you mouseover a footnote, it pops up
a tooltip.
... one footnote and three references to that footnote. If you navigate
from the second reference. it has a state and navigates back.
... note element: if you have referenced a news article (A). I write a
blog post about it (B). Block quote from article A and talk in context
about it in blob B. Another person comes and wants to talk about it in
C. It would be powerful if the reference can be linked to both article A
and to the blog B. More unification, less fracturing.
... make that blockquote an annotation. user agent could store it as
both.
... sounds abstract but is a powerful feature that is different than
HTML. Must be worked on before it's truly compelling.
fjh: very helpful. Suggested that footnotes are useful and dynamic results
paoloC: mixing up a lot of different concerns. makes argument abstract. I heard a lot of different things and applications. All different topics and complicated.
<fjh> agree with paolo, we need to review and focus discussion subsequently
shepazu: for keeping scope. stick with first
two examples - navigation to and from a footnote; rendering of footnote
in CSS.
... an aside is unstructured. it's whatever you want. A footnote or
note, as an annotation, has some structural pieces. maybe that's how to
present it.
fjh: think about it and review it and focus the discussion. Because as paoloC said, I'm also confused.
paoloC: specify what is the model part and what is the behavior part, no matter what methodology we want to adopt. good to clarify given what we want to achieve what are the different parts that we would want to define.
<Jacob_> +1 to Paolo
Ivan: I haven't talked to Mike so I do not
know what he expects.
... I don't think I can do this. It's not clear enough to me.
fjh: share on list. Think about what has been said.
shepazu: a lot of really great demos during
the hack days. Dinesh showed a lot of the cool stuff he's been working
on.
... i found the demos and the variety interesting.
dwhly: thanks to all who came to either or both events. No real updates. We will be sending out a post-workshop summary today. The key is a survey which is long overdue. Please help by filling it out. We want to try to understand how to evolve the design to other formats or even more traditional formats. Lots of anecdotal feedback.
<tbdinesh> +1 thanks dwhly
<fjh> much thanks to dwhyl and hypothes.is for I Annotate, excellent hosting for Web Annotation F2F
azaroth: Came up under protocol
conversation. If an annotation contains other annotations how does that
work with search, etc. We do not have any support from the use case or
modeling level.
... Strong desire to have the capability to create a set or to add to a
set. Focus on gathering ideas and use cases and requirements for this
topic. Introduce some use cases or ideas now. How might you use lists of
annotations? Brainstorm now; modeling in future call.
<Jacob_> This seems more like a case for collections and a collection-specific model than something that needs to be handled specifically inside of the annotation model...
<RayD> Question: what's the difference between set and container?
paoloC: I repeat my use cases from f2f: We
use them. Slice and Dice according to criteria. Access restriction and
tasks. People read documents with specific goals in mind, particular
compound, etc.
... They annotate these documents and pull them and create a report.
They read the same documents with different goals. Don't want to mix up
annotations for different goals. Different sets according to tasks. They
can also be access controlled, share with one person, group, multiple
people. !. task oriented; 2. restricted. many requests to have same
annotation in multiple sets. This causes problems.
... minimum amount of properties or data attached. If I want to be
really structured, attatch structured data as well.
... name title description should be enough.
<Jacob_> This feels out-of-scope.
paoloC: containers seems a little bit generic and not very qualified. Not sure if it matters.
<RayD> thanks!
<Jacob_> This problem is not specific to annotations
azaroth: difference between annotation sets and containers. Membership vs. identity issues.
<paoloC> :) I would probably exclude the same track multiple times in the same playlist from the metaphor
azaroth: same track multiple times, or tracks from different albums in same playlists, or you can have the same tracks in different playlists. Creation different than playlists.
<Zakim> azaroth, you wanted to add EPUB UC
azaroth: We can only answer out of scope
when we look at the use cases. Different methods of describing sets we
can treat it as out of scope. With search, we are going to end up with
lists of annotation in some format. So it would be in scope for the
working group
... to add a use case; in the work that we did with the idpf to define
annotations for ePub. There was a need for annotations for individual
epubs so that you could distribute them and have them show up on your
reader. Third-party annotations for sale or for free to be added. Like:
author notes, teacher notes, cliff notes, summaries, etc. etc.
... without sets, you would have to distribute each annotation (and
charge for each) individually.
shepazu: use case and solution from f2f: when asked, shepazu said no. he felt that chained annotations satisfied their use case. See the use case for sets in the protocol that paoloC referred to. Not sure if it's part of the data model. Or even if that is what is being suggested.
azaroth: no that is what we are talking about. That there should be a construct for sets of annotations in the data model. Readers don't need to implement multiple ways of grouping annotations.
<stain> http://www.researchobject.org/
<Zakim> stain, you wanted to relate annotation sets to ORE and researchobject.org
stain: when we were developing the research object model (group of docs, presentations with annotations). Strong need to have a unit for a group of annotations because they have a purpose. Who made this collection? Who is talking about this resource or set of resources?
<azaroth> +1 to Stain
<Jacob_> The thing is, the set model is not dependent upon the contents of the set all being annotations or even if any of them are annotations at all. We might look around and see if there are not, in fact, models that already do this work. ORE, EDM, Schema all come to mind.
stain: you have the containers but you don't have a way of accessing it without the protocol. It should be lightweight. The aggregation itself has a value. you can give it a title, a purpose.
<davis_salisbury> +1 to stain
<stain> we also used OA annotations in our Research Object bundle: https://w3id.org/bundle/#manifest-annotations
paoloC: I've been struggling with Annotation
sets for a long time. Some clients know how to handle annotation sets.
Some don't. I think having a protocol and model, if lightweight would
help implementations.
... it's complicated and you don't know what the client understands. In
the case of sets it becomes complicated. Hard to implement graceful
degradation.
<fjh> thank you Kyrce for scribing, thanks
<fjh> thanks everyone
<ivan> trackbot, end telcon