Our meeting was based around the deliverables specified in the
original project bid document:
https://docs.google.com/Doc?docid=dc4c9rrc_154d82jk9df&hl=en_GB
* Amazon Machine Image (AMI): A turn-key instance of the platform for
anyone to clone and host on Amazon's web services.
* A Virtual Box image (VDI): A turn-key instance of the platform for
anyone to host using Sun's open source Virtual Box virtualisation
application (on their own server rather than in the cloud). We could
also produce an image for VMWare, which is more popular.
* Paragraph URIs
* Syndication (inc. mediaRSS) /pull WordPress has many available feeds
and feed combinations. I blogged about this recently:
http://joss.blogs.lincoln.ac.uk/2009/04/15/addicted-to-feeds/
* Notifications/push (i.e. Twitter, FriendFeed - XMPP dropped for time
being after conversation with Automattic. I've noted this on the
relevant UserVoce 'story'. Automattic are working on this. No need for
us to do the same)
* Wave: It's quite early to be thinking about this, but Google Wave
will be launched before the end of the project and we need to consider
how we might leverage this new product/platform/protocol.
* Authoring: Tests and case studies on authoring to JISCPress.
AtomPub/XML-RPC/Email. There are MSOffice and OO plugins to publish to
WordPress. These need testing and the results of that documenting. We
need to get a good sense of how JISC funding bids are currently
authored and the workflow used. This also raises the question about
whether JISCPress is an authoring AND publishing environment or
whether it's just a publishing platform.
* Remote participation: Use of trackbacks and third-party services
such as Backtype?
* Embedding paragraphs: How can we embed JISCPress paragraphs in other
web pages? It seems reasonable to take the paragraph URI and add some
embed code to display that paragraph elsewhere. i.e. <> marks next to
the CommentPress speech bubble.
* Serialisation of documents. Using the wp-openlearn plugin to
serialise delivery of document sections via RSS/Atom over days/weeks.
We need a how-to with case studies.
* Auto discovery of related content: There are wp plugins which
examine tags and then suggest related posts based on those tags. We're
interested in looking at how we might use the OpenCalais API and
machine tags to embellish the documents with semantic tags and a
provide a richer method of discovering related content. (more on this
below) We need to consider ways of exposing a set of tags to people
and a set of tags to machines.
* Analytics: The platform will support adding google analytics to each
document and to the platform as a whole. We'll also set up PiWik, an
open source alternative to GA. Both PiWik and GA have APIs which Tony
will look at how they might be exploited.
* Page profiling: We should consider performance and green computing
issues as we're proposing a growing platform which, if inefficiently
built, will unnecessarily consume CPU cycles that affect both the user
experience and energy consumption. Both Yahoo and Google provide tools
for measuring page performance and suggesting ways to improve
performance. They are both FF plugins for Firebug:
http://code.google.com/speed/page-speed/ &
http://developer.yahoo.com/yslow/
* RDF/SEmantic web: We discussed the application of tools such as
Triplify http://triplify.org as well as OpenCalais. Triplify is
pretty easy to set up and exposes the MySQL database as RDF triples.
However, we're not clear on the benefits of doing this and need to
canvas opinion on how RDF from the platform might be used, given the
structure of WordPress' database. Here's a diagram of the single-user
WP database schema (WPMU will differ slightly and we should document
this at some point):
http://blog.kapish.co.in/wp-content/uploads/2009/03/wp_2.7.png
* We started mapping out the architecture of the platform. See here:
http://www.mindmeister.com/maps/show/22824567 Anyone can edit this.
The password is 'wpmu'
* We looked at the metadata currently shown for a typical JISC funding
call and discussed the use of categories and tags. We feel that
categories should be understood as a relatively 'stable' taxonomy
which has an organisational 'cost' and tags are 'unstable', 'cheap'
and relative to each document. JISC's current use of Themes, Topics
and Programmes would align with this interpretation of categories. See
http://jisc.ac.uk/whatwedo.aspx and the MindMap for some examples. We
also need to consider the use of custom fields and/or templates in
WordPress. Does JISC have a site architecture diagram of their
website?
* We looked at SIMAL and PROD, two JISC projects which offer
information about JISC projects.SIMAL is a semantic web browser for
JISC projects and PROD is scraping info from the JISC website and
provides a directory and RSS feeds for updates. We thought that we
might try to use both of these as services, if possible, to
pre-populate JISCPress. We need to contact these projects and discuss
how we might benefit from the work they've done. Are we a metadata
consumer? Do we need to store extended metadata? Is there an existing
schema we can use? http://prod.cetis.ac.uk/
http://simal.oss-watch.ac.uk/
* A meta-site ('archive') which aggregates content and metadata from
each document site. i.e. the WPMU site-wide-tags plugin. Need to look
at performance issues with this approach.
* Accessibility. CommentPress and the platform design in general needs
to confirm to WCAG 2.0 (I think???) Any other standards?
* Does the growing use of HTML5 affect the project at all?
* Evaluation and documentation for the use of enterprise access
management and authentication (i.e. LDAP and Shibboleth). There are
two WPMU plugins for these. LDAP is well tested (by Joss). We need to
find a friendly Shibboleth service that we can test against.
* The use of machine tags. See this for more information on machine
tags: http://www.flickr.com/help/tags/#613430 and the links to related
blog posts. We were thinking that we could use opencalais to produce
machine tags (i.e. jiscpress:tag:the_tag) which would be hidden from
normal view, but discoverable in the page source code. OpenCalais
returns automated tags which are, for the most part, useful. A small
percentage are not useful and a further small percentage are not
normal tags, which readers would expect to see. On the whole, there
might be more value in having visible tags, manually entered and
semantic tags, hidden as machine tags. Machine tags could also be
visible, if this is a requirement and appropriate
namespace:predicate:value can be agreed upon. It may, however, be too
much to expect from many document authors. A new version of OpenCalais
is due out in the next couple of weeks and we should evaluate the
service at that point for how it might be used on JISCPress. There are
existing plugins which will fetch tags from the service based on the
WordPress post content. It would be nice to tweak one of these to run
as a cron job on new documents to create machine tags. There's nothing
special about machine tags but combined with the use of Triplify, we
could then expose content, with semantic machine tags from opencalais
as RDF triples. Typically, OpenCalais will return tens of tags for
each project document or call. Try it here:
http://viewer.opencalais.com/
* Finally, we need to discuss with JISC where JISCPress would fit into
their existing web site and document workflow. Would a document be
published on JISCPress following the funding call? Will it be the
primary site for publishing funding calls? Will it primarily be a
support site that offers an online virtual town hall meeting? It
probably makes more sense for a JISCPress document site to be
published shortly after the normal document publishing process.
I think that's enough to be getting on with....
Joss
--
Joss Winn
http://josswinn.org