Anchor annotations to the closest ancestor ID?

[canadaduane]

I realize there is a group working on making annotations "stick" better when the underlying HTML structure changes; however, for my immediate needs it seems like anchoring annotations to the closest ancestor ID is a huge win over the current docroot-to-node spanning xpath. I've made a patch that achieves this, but don't know if it would be useful to others. It's backwards compatible with existing annotation xpaths.

https://github.com/wordtreefoundation/annotator/commit/c28a03b2500af0570da394d4411ea138e3cd0565

[robcast]

I would like to have something like this too. I have promoted such a feature many times (including last IAnnotate) but never got around to implementing it.

We have HTML pages generated from XML texts where we pass the XML-IDs into the HTML to use for annotations.

What code base is your patch based on?

[canadaduane]

It's based on the latest, as far as I know. I forked from openannotation/annotator master about 3 weeks ago.

[robcast]

Is it just https://github.com/canadaduane/annotator/commit/2ece8a14d562a8769bf5cd676f711f0d47321b7a ? That looks nice. I should try that once I get my code back into shape. Can the existing highlighting code deal with these anchors?

[canadaduane]

Yes, that's it. And yes, the existing code deals with these anchors (it just modifies the xpath to root at the ID rather than the doc root, so it's still a valid xpath that works everywhere it's applied).

On Tue, Jul 15, 2014 at 10:46 AM, Robert Casties notifications@github.com wrote:

Is it just canadaduane@2ece8a1 https://github.com/canadaduane/annotator/commit/2ece8a14d562a8769bf5cd676f711f0d47321b7a ? That looks nice. I should try that once I get my code back into shape. Can the existing highlighting code deal with these anchors?

— Reply to this email directly or view it on GitHub https://github.com/openannotation/annotator/issues/394#issuecomment-49059930 .

[robcast]

Cool. Since its just that small and non-intrusive I think it should go into the core code. I guess it should be configurable so that people don't suddenly get different xpaths on a code update. I would be nice as a plugin as well but I'm not sure if that's possible with the current annotator code. I remember that there was brief talk about selection/highlighting plugins at the IAnnotate conference but I don't think it is possible yet.

[canadaduane]

One thing to note is that this is a modification only to the jquery code. I think there is a fallback path for non-jquery xpaths. I didn't pursue it, however.

On Tue, Jul 15, 2014 at 11:04 AM, Robert Casties notifications@github.com wrote:

Cool. Since its just that small and non-intrusive I think it should go into the core code. I guess it should be configurable so that people don't suddenly get different xpaths on a code update. I would be nice as a plugin as well but I'm not sure if that's possible with the current annotator code. I remember that there was brief talk about selection/highlighting plugins at the IAnnotate conference but I don't think it is possible yet.

— Reply to this email directly or view it on GitHub https://github.com/openannotation/annotator/issues/394#issuecomment-49062330 .

[tilgovi]

I put this on the 2.0 milestone. I don't think it will be included, but there should be enough flexibility in 2.0 to implement this easily as a plugin or in application bootstrapping code.

[leinfelder]

Just want to vote in favor of including [something like] this feature. I'm in a similar boat as @robcast with annotations referring to underlying data, not so much what their HTML representations happen to look like today. Perhaps this means I should use more specific URIs and attach an annotator instance to each element that I want to uniquely identify in perpetuity. Thoughts?

[nickstenning]

From this point forward, I'm going to be keeping the Annotator issue tracker for bug reports only. Enhancements and feature requests should be made on the mailing list.

As this is a feature request, I'm going to close this issue. If you feel that I've miscategorised the discussion, and there is a genuine unaddressed bug, feel free to reopen with an explanation.

[canadaduane]

As a peripheral member of your community, "feature requests should be made on the mailing list" means, pretty much, that I will be making changes to my fork of the project rather than offering them back to the core. This isn't out of spite, it's just that I don't have time to be involved as a central member of many communities.

On Sun, Sep 21, 2014 at 12:08 PM, Nick Stenning notifications@github.com wrote:

From this point forward, I'm going to be keeping the Annotator issue tracker for bug reports only. Enhancements and feature requests should be made on the mailing list https://lists.okfn.org/mailman/listinfo/annotator-dev.

As this is a feature request, I'm going to close this issue. If you feel that I've miscategorised the discussion, and there is a genuine unaddressed bug, feel free to reopen with an explanation.

— Reply to this email directly or view it on GitHub https://github.com/openannotation/annotator/issues/394#issuecomment-56307137 .

[nickstenning]

I rather hope that's not the result. I'll be updating the contributing guidelines in due course, but a pull request with code for a new feature is always welcome on this repository. An issue requesting a feature doesn't help, as the core developers have no shortage of things to work on, and there's no easy way of prioritising work when the issue tracker becomes a laundry list of things people want.

So, for the sake of clarity. Welcome here on the issue tracker:

• pull requests of any description (be they to fix bugs, implement features, refactor core, whatever)
• issues identifying code or documentation bugs in released versions of Annotator

Better on the mailing list:

• discussion of possible future features
• support requests

[canadaduane]

Excellent. Thanks for the clarification.

On Sun, Sep 21, 2014 at 1:06 PM, Nick Stenning notifications@github.com wrote:

I rather hope that's not the result here. I'll be updating the contributing guidelines in due course, but a pull request with code for a new feature is always welcome on this repository, but an issue requesting a feature doesn't help, as the core developers have no shortage of things to work on, and there's no easy way of prioritising work when the issue tracker becomes a laundry list of things people want.

So, for the sake of clarity. Welcome here on the issue tracker:

• pull requests of any description (be they to fix bugs, implement features, refactor core, whatever)
• issues identifying code or documentation bugs in released versions of Annotator

Better on the mailing list:

• discussion of possible future features

— Reply to this email directly or view it on GitHub https://github.com/openannotation/annotator/issues/394#issuecomment-56308905 .

[leinfelder]

Hi Nick, As a very new member of this community, I found it extremely useful to browse the list of "issues" in this centralized github location. I started to comb through the email list archives, but that was rather tedious and getting the full context of any particular topic was, well, difficult (and maybe I missed it, but it was also not searchable).

One of the great things about the github "issues" is that you can annotate them with labels and then filter by those labels. Perhaps a "bug" label could be used to differentiate between an "enhancement" or a "discussion". This would allow the core developers to focus on critical problems with released code as well as engage a [somewhat peripheral] group of stakeholders in the discussion and planning. It would also allow people like me and Duane get a sense for what is coming in future releases and whether the kinds of features we might want are forthcoming and beneficial for the broader community.

My inbox is already quite cluttered, and it's is a tranquil relief to come here to participate in open discussions with like minded developers like you. Thanks and I hope that wasn't too preachy for a new person! -ben

[tilgovi]

While having feature requests here does make a nice, browseable set of things, it doesn't reliably give anyone a sense of what's coming in the future, because we may never get to it at all.

I submitted the mailing list to Gmane.org a while back so it should be searchable (though uptime on their search seems to be shaky).

I also think consolidating too many feature requests here doesn't adequately encourage people to make new, dependent projects, tending instead to push the core toward monolithic framework and not slim, flexible library.

But I'm really happy to hear more voices on this. Feel free to tell me I'm missing the point.

[leinfelder]

Certainly, feature requests need to be triaged to be useful to anyone - especially the core team. It seems like having those potential items in a forum like this is a good way to organize and evaluate them through discussion and informal voting just like we are doing now. On this topic alone, there are three different people clamoring for the feature and one [possibly] threatening to fork and never look back; not the kind of new projects we want to be encouraging...

It seems like you do your project planning and outreach on github, so I'm not sure why you wouldn't want all the information to do that planning in that same location. There are already "question", "enhancement" and "Backlog" labels as well as a "v2.0" milestone. Why not use them to your benefit? Questions become a ready-made FAQ section and reduce traffic on your email list over time, while enhancements allow you to do informed project planning in a transparent way. Collaboration Shangri-La!

[tilgovi]

On Sep 21, 2014 2:54 PM, "leinfelder" notifications@github.com wrote:

Certainly, feature requests need to be triaged to be useful to anyone - especially the core team. It seems like having those potential items in a forum like this is a good way to organize and evaluate them through discussion and informal voting just like we are doing now. On this topic alone, there are three different people clamoring for the feature and one [possibly] threatening to fork and never look back; not the kind of new projects we want to be encouraging...

(For anyone just tuning in, there was no hostility or real divergence, we're just discussing contribution processes on GitHub, and triage etiquette.)

It seems like you do your project planning and outreach on github, so I'm not sure why you wouldn't want all the information to do that planning in that same location. There are already "question", "enhancement" and "Backlog" labels as well as a "v2.0" milestone. Why not use them to your benefit? Questions become a ready-made FAQ section and reduce traffic on your email list over time, while enhancements allow you to do informed project planning in a transparent way. Collaboration Shangri-La!

I'm hearing you.

I'll cross post this to the mailing list, because even as we talk about it I'm concerned that we're excluding precisely the audience that would potentially object :-D.

I don't have a sense of whether there's a big constituency that agrees, but I consider email the most accessible collaboration medium for a diverse audience of maintainers, developers, and users.

For all that is great about GitHub, folks have at their disposal a diversity of tools and practices for sorting, organizing, prioritizing, drafting, and conversing via email.

I don't have any problem with enhancements having GitHub tickets, but I do think it's important to have an active mailing list and that it is the best place to establish fitness for inclusion and community interest when discussing proposed changes and features ahead of implementation.

:-/

As Nick said, reopen anything that gets closed if you want to look at it again. I don't think that's mutually exclusive of encouraging use of the mailing list.

If you find email useful or you think it fragments and or hides things you'd rather have on GitHub, speak up, whatever your thoughts! I am perennially somewhat enamored with this conversation (really!) each time it comes up somewhere I subscribe.

I think my preference is to take your thoughts about FAQ, roadmap, etc, and to turn that into better documentation that is in the repo, which would provide that transparency of purpose and scope to reduce bewilderment, but for active discussion of proposals pre-implementation we simply document and encourage email as preferred first contact.

Reasonable? Dumb and backward? Heh. I don't know!

[tilgovi]

On Sun, Sep 21, 2014 at 7:20 PM, Randall Leeds randall@bleeds.info wrote:

On Sep 21, 2014 2:54 PM, "leinfelder" notifications@github.com wrote:

Certainly, feature requests need to be triaged to be useful to anyone - especially the core team. It seems like having those potential items in a forum like this is a good way to organize and evaluate them through discussion and informal voting just like we are doing now. On this topic alone, there are three different people clamoring for the feature and one [possibly] threatening to fork and never look back; not the kind of new projects we want to be encouraging...

(For anyone just tuning in, there was no hostility or real divergence, we're just discussing contribution processes on GitHub, and triage etiquette.)

+1 for making that clear to the "by standards" (like myself). :)

It seems like you do your project planning and outreach on github, so I'm not sure why you wouldn't want all the information to do that planning in that same location. There are already "question", "enhancement" and "Backlog" labels as well as a "v2.0" milestone. Why not use them to your benefit? Questions become a ready-made FAQ section and reduce traffic on your email list over time, while enhancements allow you to do informed project planning in a transparent way. Collaboration Shangri-La!

I'm hearing you.

I'll cross post this to the mailing list, because even as we talk about it I'm concerned that we're excluding precisely the audience that would potentially object :-D.

I don't have a sense of whether there's a big constituency that agrees, but I consider email the most accessible collaboration medium for a diverse audience of maintainers, developers, and users.

This may not come as a shock, but lots of communities are (and likely have) been dealing with this same issue. Here's a thread I was recently apart of (on GitHub): https://github.com/jgm/stmd/issues/126

I ended up in that thread because of being told I was in the wrong place and needed to repost. :-( https://github.com/jgm/stmd/issues/121

The frowny face is because it shut down my (current) interest and activity with that project--as I have no (current) desire to sign-up for another account on another site to post the same message to the same people.

tl;dr It's your project. You curate it. I'm just here to help.

It maps to the Principle of Least Effort: http://en.wikipedia.org/wiki/Principle_of_least_effort

In this case (again, currently) the bar was too high for my time / interest / attention, so it shut down my participation.

I'd have preferred it (and offered as much) that they re-post on my behalf to wherever they want to keep stuff, and link it from the place I'd originally put it. Like it's a Web or something. :-P

While AnnotatorJS (and any other project) should have it's preferred mode, storage locations, etc, none of that should inhibit someone's interaction with the project.

Committers / team-members / whoever, should feel free to curate how they like, and route people with URL's and links as needed!

The tricky bit is dealing with all the self-inflicted walled gardens, but that shouldn't be your brand-new-community-participants problem.

Help them help. :)

For all that is great about GitHub, folks have at their disposal a diversity of tools and practices for sorting, organizing, prioritizing, drafting, and conversing via email.

On the email front, Randall's spot on. Few things beat email when it comes to the range of tooling for managing one's own chaos. :)

Perhaps the help to the "self-inflicted walled gardens" problem (for now) is to use something like Zapier.com to at least make the Mailing List (presumably having a wider audience than GH) aware of activity on GitHub by have Zapier send emails on New Issues (at least).

The wall is still there for interaction, and it's quite possible there'd be 2 conversations going on, but at least one group wouldn't be "lesser" than the other.

That said, all of this is "self-inflicted" pain (perhaps unavoidably so at the moment), and causing it to new comers is the real danger.

Anyway.... :)

To quote Randall from earlier: "...there [is] no hostility or real divergence...just discussing contribution processes on GitHub, and triage etiquette."

Every open source community is, has, or will be facing this at some point.

It's a nice problem to have, actually. :)

Thanks for listening, Fairly-new-comer Benjamin ;)

I don't have any problem with enhancements having GitHub tickets, but I do

think it's important to have an active mailing list and that it is the best place to establish fitness for inclusion and community interest when discussing proposed changes and features ahead of implementation.

:-/

As Nick said, reopen anything that gets closed if you want to look at it again. I don't think that's mutually exclusive of encouraging use of the mailing list.

If you find email useful or you think it fragments and or hides things you'd rather have on GitHub, speak up, whatever your thoughts! I am perennially somewhat enamored with this conversation (really!) each time it comes up somewhere I subscribe.

I think my preference is to take your thoughts about FAQ, roadmap, etc, and to turn that into better documentation that is in the repo, which would provide that transparency of purpose and scope to reduce bewilderment, but for active discussion of proposals pre-implementation we simply document and encourage email as preferred first contact.

Reasonable? Dumb and backward? Heh. I don't know!

---

annotator-dev mailing list annotator-dev@lists.okfn.org https://lists.okfn.org/mailman/listinfo/annotator-dev Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev

[tilgovi]

Email is fantastic as an alert mechanism.* As an archive, it only works if I was subscribed when the discussion began or if there is a reliable, easy to use, and easy to point to repository for prior questions and discussions.

Benjamin was able to point us to two relevant conversations in a project I certainly was not part of, or even aware of…because they were recorded in GitHub. I can explore the entire thread, learn the context of the discussion and maybe even the resolution if I choose to watch the topic. That seems really useful to me.

Maybe the gmane.org route will work for you. Mentioning that archive somewhere obvious would be useful so that new people like me can do their own legwork before bogging down the list with redundant "how do I…?" or "what do you think about…?" questions. But I think I'd feel awkward joining in the conversation if I had to open an entirely new email with, "hey guys, I saw you were talking about this back in May, thought I'd chime in with my thoughts now…"

Thanks, -ben

*and cat gifs

On Sep 22, 2014, at 8:57 AM, Benjamin Young bigbluehat@hypothes.is wrote:

On Sun, Sep 21, 2014 at 7:20 PM, Randall Leeds randall@bleeds.info wrote: On Sep 21, 2014 2:54 PM, "leinfelder" notifications@github.com wrote:

Certainly, feature requests need to be triaged to be useful to anyone - especially the core team. It seems like having those potential items in a forum like this is a good way to organize and evaluate them through discussion and informal voting just like we are doing now. On this topic alone, there are three different people clamoring for the feature and one [possibly] threatening to fork and never look back; not the kind of new projects we want to be encouraging...

(For anyone just tuning in, there was no hostility or real divergence, we're just discussing contribution processes on GitHub, and triage etiquette.)

+1 for making that clear to the "by standards" (like myself). :)

It seems like you do your project planning and outreach on github, so I'm not sure why you wouldn't want all the information to do that planning in that same location. There are already "question", "enhancement" and "Backlog" labels as well as a "v2.0" milestone. Why not use them to your benefit? Questions become a ready-made FAQ section and reduce traffic on your email list over time, while enhancements allow you to do informed project planning in a transparent way. Collaboration Shangri-La!

I'm hearing you.

I'll cross post this to the mailing list, because even as we talk about it I'm concerned that we're excluding precisely the audience that would potentially object :-D.

I don't have a sense of whether there's a big constituency that agrees, but I consider email the most accessible collaboration medium for a diverse audience of maintainers, developers, and users.

This may not come as a shock, but lots of communities are (and likely have) been dealing with this same issue. Here's a thread I was recently apart of (on GitHub): https://github.com/jgm/stmd/issues/126

I ended up in that thread because of being told I was in the wrong place and needed to repost. :-( https://github.com/jgm/stmd/issues/121

The frowny face is because it shut down my (current) interest and activity with that project--as I have no (current) desire to sign-up for another account on another site to post the same message to the same people.

tl;dr It's your project. You curate it. I'm just here to help.

It maps to the Principle of Least Effort: http://en.wikipedia.org/wiki/Principle_of_least_effort

In this case (again, currently) the bar was too high for my time / interest / attention, so it shut down my participation.

I'd have preferred it (and offered as much) that they re-post on my behalf to wherever they want to keep stuff, and link it from the place I'd originally put it. Like it's a Web or something. :-P

While AnnotatorJS (and any other project) should have it's preferred mode, storage locations, etc, none of that should inhibit someone's interaction with the project.

Committers / team-members / whoever, should feel free to curate how they like, and route people with URL's and links as needed!

The tricky bit is dealing with all the self-inflicted walled gardens, but that shouldn't be your brand-new-community-participants problem.

Help them help. :)

For all that is great about GitHub, folks have at their disposal a diversity of tools and practices for sorting, organizing, prioritizing, drafting, and conversing via email.

On the email front, Randall's spot on. Few things beat email when it comes to the range of tooling for managing one's own chaos. :)

Perhaps the help to the "self-inflicted walled gardens" problem (for now) is to use something like Zapier.com to at least make the Mailing List (presumably having a wider audience than GH) aware of activity on GitHub by have Zapier send emails on New Issues (at least).

The wall is still there for interaction, and it's quite possible there'd be 2 conversations going on, but at least one group wouldn't be "lesser" than the other.

That said, all of this is "self-inflicted" pain (perhaps unavoidably so at the moment), and causing it to new comers is the real danger.

Anyway.... :)

To quote Randall from earlier: "...there [is] no hostility or real divergence...just discussing contribution processes on GitHub, and triage etiquette."

Every open source community is, has, or will be facing this at some point.

It's a nice problem to have, actually. :)

Thanks for listening, Fairly-new-comer Benjamin ;)

I don't have any problem with enhancements having GitHub tickets, but I do think it's important to have an active mailing list and that it is the best place to establish fitness for inclusion and community interest when discussing proposed changes and features ahead of implementation.

:-/

As Nick said, reopen anything that gets closed if you want to look at it again. I don't think that's mutually exclusive of encouraging use of the mailing list.

If you find email useful or you think it fragments and or hides things you'd rather have on GitHub, speak up, whatever your thoughts! I am perennially somewhat enamored with this conversation (really!) each time it comes up somewhere I subscribe.

I think my preference is to take your thoughts about FAQ, roadmap, etc, and to turn that into better documentation that is in the repo, which would provide that transparency of purpose and scope to reduce bewilderment, but for active discussion of proposals pre-implementation we simply document and encourage email as preferred first contact.

Reasonable? Dumb and backward? Heh. I don't know!

---

annotator-dev mailing list annotator-dev@lists.okfn.org https://lists.okfn.org/mailman/listinfo/annotator-dev Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev

---

annotator-dev mailing list annotator-dev@lists.okfn.org https://lists.okfn.org/mailman/listinfo/annotator-dev Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev

[luxio]

@canadaduane thank you so much for sharing this. This was exactly what I was looking for. 👍🏻