Warning:
This wiki has been archived and is now read-only.
Publisher preferences
Contents
Goals
- mechanism for both annotations and more traditional comments
- a system with mutual benefits to authors, publishers, and annotation / comment systems
- not just about abuse, but also about opportunities (so "consent" might not be the best framing)
- allow authors / publishers to express comment preferences
- provides basic tools to foster distributed ecosystem, while setting realistic expectations that may be honored by fledgling annotation services
- make a distinction between:
- personal (local) annotations
- public annotations (e.g. on an annotator's publishing feed, as on Twitter)
- display in context of author / publisher page
- moderation preferences
- provide means to advertise:
- contact info for author / publisher to be sent annotation notifications
- comment / annotation service hosted by author / publisher
- preferred annotation / comment services, because of:
- partnerships (e.g. "share this on Reddit or Facebook or new-service-trying-to-get-noticed", or hosted comment services like LiveFyre, Disqus, etc.)
- topicality (e.g. a favorite political or new publisher, a trusted comment service that specializes in peer review on this particular sub-topic of biomolecular engineering)
- use of trusted moderation methods or thresholds
- avoid introducing new markup (elements/attributes) into HTML, etc.
- addresses the proxy-hosting of annotated content
- reuse existing mechanisms where possible
- allow easy per-page application:
- for authors / publishers without server access
- for individual author preferences (in case of single-page article aggregation)
- for espressing different consent and partners for each article (e.g. "comments closed for this article", sensitive topic in specific post)
- for expressing author preferences across all their articles
- preferably some parts can be expressed in link elements in the body, since many environments limit authors to that
- ease of implementation for blog / publishing platforms, including plugins
- enable external meta-moderation, e.g. subscription to third-party whitelists / blacklists for services / aggregators
- allow individual annotations to express the target's preference, for client / service / aggregator / user filtering
- allow individual annotations to express their own comment preferences preferences, for annotations on annotations
- avoid rigid enforcement mechanism, for flexible interpretation by annotation client / service / aggregator / user, while still being clear about preferences, and allowing comment clients and services to compete on policies; for example:
- an annotation service or client may selectively honor comment preferences on an individual blog, but not on a news site or a government site; where would a large corporation fit here? again, that's up to the service
- an annotation service or client may automatically determine suitability for "overriding" preferences based on multiple factors, including stated preference or subscription to sets of whitelists / blacklists
- a client may selectively allow user to override default filters to see some "hidden" comments and annotations (based on variable criteria)
TODO
- Consider non-HTML content… could embed as image metadata, or serve in HTTP headers
- Consider aggregated authors, as in multi-article blog view:
- <meta> doesn't allow for multiple values
- can't use <meta> in body, for each article
- use additional author-contact mechanism for inline HTML? Maybe RDFa pref on author name?
- in <meta>, default to most restrictive article in aggregation?
- doesn't consider "personal message" or sets of rationale; might be good social engineering, but not yet a clear mechanism, and free form risks misuse
- doesn't suggest preference for moderation method or thresholds
- consider related case of copyright, e.g. the rational for expressing preferences is different than for harassment
Proposal
Comment preferences
meta name "comment-prefs" (or possibly "comment-preferences" or "comment-consent")
<meta name="comment-prefs" content="nocomment">
Possible values:
- "nocomment": The publisher prefers that no comments or annotations are made about the page
- "noselection": The publisher prefers that annotations do not include selections from the page to be published elsewhere
- "nopublic": The publisher prefers that no public (e.g. only private) comments or annotations are made about the page
- "nodisplay": The publisher prefers that annotations made about the page are not displayed in the context of the page (e.g. not overlaid on top of content or in a sidebar)
- "moderated": The publisher prefers that comments or annotations made about the page be published on their own comment/annotation service for moderation before being displayed in the page's context, to be paired with the appropriate <link>
In body content
These preferences would optimally be expressable in <a> elements in the <body>, since many environments don't let authors modify <head> content like <meta> or <link>
HTML has a mechanism to indicate the page author, using a link with rel="author".
<a href="http://example.com/john" rel="author">John</a>
or:
<a href="mailto:john@example.com" rel="author">John</a>
Should we use RDFa to express "comment-prefs", on the author name link?
Moderation service
We may wish to allow publishers to point to a service where comments and annotations are subject to moderation:
<link rel="comment-moderation" href="[url]">
External blacklist / whitelist subscriptions
Easier to manage as Web services change over time.
Whitelist: list of approved annotation services for allowed context display:
<link rel="comment-whitelist" href="[url]">
Blacklist: list of banned annotation services for disallowed context display:
<link rel="comment-blacklist" href="[url]">
Preferred or advertised comment services
Sometimes a publisher will have their own comment or annotation service that they want comments published to. Alternately, a publisher will have preferred partner services, such as a paid third-party service (e.g. LiveFyre or Disqus) that handles all the site's comments, or a social network (e.g. Reddit, Facebook, Twitter), or a topic-appropriate discussion forum (e.g. a trade-specific journal, a news site, or a political site).
In this case, publishers can advertise one or more preferred comment services:
<link rel="comment-service" href="[url]">
Multiple services can be indicated by multiple links, with one service per link.
This proposal doesn't currently make a distinction between the publisher's comment service and their partners, or an ordered preference (though that might be useful).
Proxied Annotated Content
This is related to annotation, making it easier to view annotated content without users having the browser extension, but it's a separate issue. This is already addressed by the "robots" meta name:
<meta name="robots" content="noarchive">
There could be a separate name/value, which refers to license issues about reuse of selections. Or perhaps "nosnippet"?
Notifications
Publishers sometimes want to be notified when a comment or annotation is made about their site.
We can reuse Webmention for this:
"Webmention is a simple way to notify any URL when you link to it on your site. From the receiver's perspective, it's a way to request notifications when other sites link to it."
Link: <http://aaronpk.example/webmention-endpoint>; rel="webmention"
<html> <head> ... <link href="http://aaronpk.example/webmention-endpoint" rel="webmention" /> ... </head> <body> .... <a href="http://aaronpk.example/webmention-endpoint" rel="webmention">webmention</a>
Non-HTML content
Some target resources (content that might be annotated) isn't HTML, or you might prefer not to modify an HTML target resource. In this case, you can express the preferences via the HTTP response headers.
You can also do both HTML elements and HTTP response headers. When retrieved from a server, the HTTP header takes precedence. For local files, or aggregated content, where HTTP headers are not available or are lost, so the <meta> and <link> elements are more portable.
For any <link>, like this:
<link rel="meta" href="meta.txt"/>
here is the response header equivalent:
Link: <meta.txt>; rel=meta
See https://www.w3.org/wiki/LinkHeader
I don't know if you can do this with <meta> content.
Future extensions to Annotation Data Model
Carrying publisher preferences
In order to allow users, clients, and services to selectively honor target-publisher preferences while still publishing the annotation, we will need additional metadata within the annotation.
"target": {
"source": "http://example.org/page1",
"prefs": "nodisplay",
...
}
Service Exceptions
If a service chooses to selective honor (or override) publisher preferences, we could allow freeform comments as a rationale for why the service made an exception.
"target": {
"source": "http://example.org/page1",
"prefs": {
"content": "nodisplay",
"exception": "government site"
},
...
}
Comment Preference about Annotations
We could also allow comment preference about annotation itself:
"body": {
"type" : "TextualBody",
"text" : "I don't want anyone to comment on this annotation!",
"format" : "text",
"language" : "en",
"prefs": "nocomment"
}
Registries
- <meta> name="" attribute values are registered on https://wiki.whatwg.org/wiki/MetaExtensions
- rel="" attribute values are registered at http://microformats.org/wiki/rel-registry and http://microformats.org/wiki/existing-rel-values