Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] Iterate the Web Annotation Data Model itself #41

Open
BigBlueHat opened this issue Dec 12, 2017 · 7 comments
Open

[Proposal] Iterate the Web Annotation Data Model itself #41

BigBlueHat opened this issue Dec 12, 2017 · 7 comments

Comments

@BigBlueHat
Copy link
Member

The Web Annotation Data Model needs iteration...but I'm not sure the Web Publishing WG is the place to do it...yet.

Given #38 and #40, there seems to be a need to iterate on the Web Annotation Data Model specification itself, and not merely extend it.

Much of what is currently in the publ-loc spec is focused on a Web Publication format that itself is not yet defined thoroughly enough to implement, and defining selection strategies for it and stream-related position systems seems premature.

That said, all these things should be explored (as well as addressing #40).

Proposal

Create a new version of the Web Annotation Data Model and Web Annotation Vocabulary specifications which would:

  • address "Selectors" is already normatively defined #40
  • work on "contained resource" selection/locating/targeting
  • work on "cross-resource" selection/locating/targeting
  • address any Web Publication specific annotation needs (as WP and PWP become more defined with clearer needs and use cases)

The place for this work to happen at the moment is the Open Annotation Community Group. Obviously, that group is not chartered to publish a Technical Recommendation. So, here are two options for providing that service:

  1. the Web Publishing Working Group (with its notable overlap in membership with the OA CG) upstreams the work done in the OA CG's document(s) and publishes the next iteration of Web Annotation Data Model and Vocabulary as Technical Recommendations under its banner/charter
  2. (alternatively) a new Web Annotation Working Group is chartered (born out of publishing needs...again) and this new Working Group does the document iterations, explores the needed features with the Publishing WG (and other WGs), and publishes any Technical Recommendations.

Option 1 seems most likely to be effective and achievable given the overhead of chartering new working groups within the W3C. Potentially, both can be done with Option 1 happening now by simply beginning the conversations of iteration at the Open Annotation CG. Option 2 (should it be possible) could follow later and pick up from the work of the OA CG (just as the original Web Annotation WG did).

Thoughts?

@iherman
Copy link
Member

iherman commented Dec 12, 2017

@BigBlueHat, we are not chartered to do that. That would require a separate working group or a rechartering of the current one.

@TzviyaSiegman
Copy link

I believe @BigBlueHat is proposing a new WG. Perhaps this conversation should be moved to email?

@iherman
Copy link
Member

iherman commented Dec 12, 2017

My apologies, @BigBlueHat and @TzviyaSiegman, I should have been more clear. What I wanted to say is that option 1 is not an option. Only option 2 is... Which also means that, indeed, we should either move this discussion to email or to the issue list of the WG, because it is not directly relevant to the locator spec...

(Lesson: never write a comment quickly, when you are already supposed to cook dinner:-)

@tcole3
Copy link
Collaborator

tcole3 commented Dec 13, 2017

Personally I disagree with the premise. The Web Annotation Data Model and Vocabulary is being used and while far from perfect, I think it too early to decide a major re-write is in order.

All proposed updates except the misappropriation of the term 'selector' (#40) can be handled by domain-specific extensions of the published data model and ontology. This is explicitly allowed for by the specs. And I do not think the misappropriation of the term 'selector' is sufficient to justify re-chartering the Web Annotation Working Group. More appropriate would be for the OA CG to approve an errata entry to change Selector to (for example) Locator, which would be facilitated if we retitled our document so as to stop overloading the term 'Locator' as we have (also means we would have to live with 'Specific Resource' or come up with yet another term not already normatively defined).

If it becomes clear that a more fundamental rewrite is required for uptake in the Publishing community, and if it can be done without making existing uses of the Web Annotation data model obsolete, then we would have to make a case to re-charter the working Group.

The only upside I see to iterating the WA Data Model at this time to address the issues raised is that we could have everything in a single document. While noble in thought, this is proving a pipe-dream in practice.

@BigBlueHat
Copy link
Member Author

This spec introduces referencing points inside of documents contained or "just" references from inside other documents in ways that the Web Annotation Data Model spec only lightly touches on via the scope property and examples about annotating an image referenced inside a certain Web page.

We're potentially reaching a good bit farther--depending on what WP and PWP actually become.

More appropriate would be for the OA CG to approve an errata entry to change Selector to (for example) Locator, which would be facilitated if we retitled our document so as to stop overloading the term 'Locator' as we have (also means we would have to live with 'Specific Resource' or come up with yet another term not already normatively defined).

I agree that re-titling the document is necessary to avoid messing up any future use of the word "Locators." However, I don't think errata is a sufficient tool to solve that--nor anything else, really...

We can't even fix broken links (one of them my fault...) in the spec: https://www.w3.org/TR/2017/NOTE-annotation-html-20170223/#bib-selectors-states So, I rather doubt that people will go to the Errata and dig around in there to see if someone possibly changed a fundamental term in the vocabulary or context--which we also can't change without WG-level authority. Developers copy/paste out of specs. When those specs are wrong, the implementations are wrong. No one reads out-of-band errata.

There needs to be some hybrid model that sits between this "printed" specification model and the "living standard" model.

Web Annotation needs iteration, but I'm not sure the Web Publishing group has enough experience with annotation tooling and data models to be that group--nor the authority to change the "old" files in a way that meaningful results in a proper upgrade to Web Annotation.

@iherman
Copy link
Member

iherman commented Dec 14, 2017

I would propose to move this discussion to the Web Annotation CG. That is the group chartered to maintain the Errata, to possibly come up with new drafts, and, again possibly, with a proposal and work plan for a new group. This WG and this repo is not the right place for this...

@BigBlueHat, do you think you can initiate a discussion in that group (and, if this is successful, close this issue)?

@tcole3
Copy link
Collaborator

tcole3 commented Dec 14, 2017

And just to be clear, my suggestion was that the errata could handle the misappropriation of the Selector term. I was not trying to address all the other concerns you mention.

It may be useful to start by identifying what we can / want to do by errata first.

The Selector terminology issue seems fine for errata because it's a distinction not essential for most implementers - simply about clearing up a possible (but largely unlikely) confusion, and perhaps making it easier in our new web publishing document to get away from using the Selector term incorrectly going forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants