As part of the JISCPress effort, one of the things we’ve been considering is the granularity of appropriate “consultation elements” or “discussion elements”, those pieces of content that people might actually want to reference, question or chat around as compared to a whole 200 page document, for example.
The page and paragraph levels fall out of the CommentPress theme (and its descendants) quite naturally – WordPress gives us the page level (along with a single item RSS feed at the page level), and the theme gives us URIs at the paragraph level.
(Hmmm… I wonder – would it also be useful to provide a multi-item RSS feed, at the page level, with a separate item for each paragraph on that page? Or do we do that already?!)
In many cases, the paragraph level seems to be the most natural chunk for discussion, particularly in an ongoing conversation about a particular document. So a major question for us is how to put those paragraphs to work?
One of the features that Eddie’s been working on as part of the JISCPress project is the ability to embed paragraphs from a document in third party web page. This feature will allow us to increase the surface area of the document by allowing third parties to re-present that content elsewhere, whilst also (hopefully) providing a means to link that external conversation directly back to the original document.
So what benefits does embedding have to offer to:
a) the person grabbing and using the embed code;
b) the publisher/whoever’s running the consultation from which the embed code was grabbed
In a discussion on the JISCPress group, Joss suggested the following:
For the user:
1. More portable transformation of document content into raw data.
2. Personalisation, presentation and ‘ownership’ of documents within their own publishing environment (which is one of the benefits of slideshare/scribd).
3. Direct joined up quoting rather than copying. More aligned with the ideals of the web and linking data. This could also be a benefit to publishers concerned about unattributed copying.For the publisher:
1. Greater possibilities of content dissemination
2. Greater potential of attracting engagement via trackbacks
3. Further possibility of using JISCPress as an underlying ‘document store’ where authoring, dissemination and engagement occurs mostly remotely via XML-RPC, syndication, embeds and trackbacks.
4. Possibility of site analytics being hooked into embeds so the reach is measurable???? (Analytics can track document types, I’m not sure whether they are used to track embeds…)
So where are we at? Embedding is currently in testing and has the following mechanic. Hovering your mouse cursor over one of the paragraph numbers in a document raises a floating panel that contains a link to the current paragraph, and an embed code. (The panel remains open whilst the cursor is over it, so you can easily grab a copy of the code.)
Using the embed code in a third party page embeds the corresponding paragraph in that page.
For testing purposes, the pattern we are using for the embed URL is of the form:
http://docserver.example.com?p=POSTNUMBER&digress-embed=PARANUMBER
The POSTNUMBER identifies the actual page (i.e. http://docserver.example.com?p=POSTNUMBER is a valid page URI) and the PARANUMBER identifies the paragraph to be embedded. Note that this is subject to change.
Unfortunately, the simple embed strategy does not trivially generate a linkback (such as a trackback or pingback) to the original document. For these reverse links to be generated automatically, an actual anchor tag linking back to the original page must be present in the page creating the linkback. One commonly used strategy for achieving this is to provide an embed code of the form:
<div>
<object />
<a>Quoted from etc…</a>
</div>
That is, a link is explicitly included in the embed code, although it is easy enough for the person embedding the quote to strip that anchor tag out.
(Although it complicates matters, as the embedded object is being pulled from the document server, I guess that means we could, in principle, generate a linkback by observing the referrer page URIs for requests made on the server for particular embeddable objects and checking those against the current list of trackbacks? Or maybe the embedded object could generate an XML-RPC back to the trackback server itself whenever the page it is embedded in is loaded? [Note to self: can we easily get analytics on third party embeds?] I think Eddie is working on this, so I won’t embarrass myself further wittering on about things I don’t know anything about!;-)
Note that a similar problem arises when using a Javascript (<script> tag) based embed code: there is no explicit anchor link present. Script tags also have the additional problem that they are often sanitised (i.e. stripped out) of web pages in many institutional web publishing systems. (In some circumstances, a workaround for the institutional case may be possible. For example, if a variant of WTR/JISCPress was running as a white label solution in an institution, a shortcode plugin could be provided that allowed authors to embed paragraphs from documents in that environment within other documents in that environment. See the WordPress shortcode API for more details.)
As well as the straightforward embed code, we’ve also been considering other ways in which paragraph level content can be published so that third parties have convenient access to it in a format that is appropriate for their needs.
And this is what we came up with – an output switch that can be appended to the end of a paragraph URI that allows the paragraph level content to be published in a variety of formats:
- &output=html
- &output=rss
- &output=txt
- &output=js
- &output=json
As and when these come on stream, we’ll publish use-case examples for each of them.
If you have any comments on our “paragraph republishing” strategy, please post a comment below.