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.

wordtreefoundation@c28a03b

[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 canadaduane@2ece8a1 ?
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/annotator@2ece8a1
canadaduane@2ece8a1
?
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
#394 (comment)
.

[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
#394 (comment)
.

[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
#394 (comment)
.

[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
#394 (comment)
.

[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