incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ichiro Furusato <>
Subject Re: From Plugin to something completely different... that users need!
Date Mon, 12 Nov 2012 11:33:04 GMT
On Mon, Nov 12, 2012 at 12:53 AM, Christophe Dupriez <> wrote:
> Ichiro, please allow me to be very enthusiastic about your message!

Hi Christophe,

Thanks - I appreciate the enthusiasm. I've got about a half an hour this evening
to do some emails, so pardon me if I don't address all your many points.

> So, if you have somewhere some demo of your work, I would happy to look at
> it.

Sorry, no, the earlier implementations are tied to a specific,
unreleased project. What I've got now is an almost-complete
greenfields implementation of the existing node and link APIs,
and several implementations for those APIs (using Berkeley DB
JE, JGraphT, and Neo4j). From the implementations you may guess
this is basically a graph database, where the nodes have an API
and the links another API.

There's actually a required "root" node called the Reference
node, such that every node in the database is either connected
to the reference node or to a node in some way connected to the
reference node -- there are no "island" nodes -- all nodes in
the database are connected to something (it's a single graph).
My plans are to build a link manager akin to a simplified
version of Arbortext's Dynamic Link Manager (DLM) to handle all
links using a persistent identifier service. The entire backend
would be also available via an Apache Wink-based RESTful
web service (JSPWiki could either access the database via its
Java API or via REST, though I'm not sure with the latter how
security would be managed).

As I think I've mentioned previously, a node stores name-value
pairs, where the metadata is whatever you want to store along
with the node, and the wiki body is simply another property. This
is kinda how JackRabbit works -- i.e., it doesn't differentiate
content from metadata, or just considered the document body
as more metadata. I at first thought that was strange but I
couldn't find a reason why it should be considered "wrong".

What does this potentially mean for JSPWiki? Well, my guess is
that a graph database would suit a flat wiki, but could also
a hierarchical wiki. Revision control could be implemented as
graph nodes as revisions connected to the "main" page, with
links maintained between revisions. This conversation has me
thinking about actually doing some coding, and I've begun to
first implement WikiProvider and WikiPageProvider. I can
release something once those APIs are functional.

> Another point is that is one wants to integrate for passive
> SEO, (s)he will have to find a way to insert structured data:
> 1) for the whole current page (e.g. data about a family of products, a
> person, an organisation)
> 2) for references in the page (e.g. references to people of an organisation,
> to products of a products' family, etc.)
> 3) for references in the page providing additional information (e.g. retail
> prices of the products from a given product family)

I think these are reasonable use cases but do not think they'd be
part of the core of JSPWiki -- they'd be extensions of some sort,
probably plugins.

> For 1):
>   a) identification: my integration with SKOS management is a solution for
> the applications I develop
>   b) linked attributes/properties: your solution needs to be investigated !
> For 2), this could be coded using InterWiki links (a given prefix can be
> associated to an object class and dynamic display could format this
> correctly. In the example above, InterWiki links of type "jita" is linking
> to
> For 3), it is more difficult as it means to combine a scope (part of the
> text) and inserted properties values: does your metadata encoding could
> provide a solution here?

I've worked with a number of plugins that attempted some structured
data. If the above-described graph backend were available I'd suggest a
relatively simple plugin that linked structured data nodes (as separate
nodes in the database) to instances of plugin references, where the
plugin would dereference the link and handle the rendering of the data
(the wiki would do nothing except supply the wiki plugin support). How
to create, edit and maintain those nodes, well, that would be another

> About wiki markup:
> i) I did not succeeded to have MDs learning it well. They prefer CK editor
> by far (especially it cut and paste from Word capability)
> ii) CK is XHTML. Converting from WikiMarkup to XHTML is OK. Converting back
> from XHTML to WikiMarkup is a nightmare. For instance, paragraphs within
> table cells cannot be supported. Plugins insertions are difficult to
> retro-convert correctly, etc. If for the different reasons Jane, Florian and
> you mentionned, we should stick to WikiMarkup, we need to have a process
> where the user is prevented to make things that are not supported (without
> destroying the content). I think Florian proposal to describe in details the
> translation is a very good one.

If the XHTML is well-formed I would suggest the *only* way to convert it
back into WikiMarkup would be XSLT. But yes, I agree that is all pretty
difficult to do. I'm aware of all the long-standing discussions about
interwiki markup using something like XHTML or bespoke XML markup
(discussions on CommunityWiki, MeatballWiki, etc.).

> Practically, I would like to put efforts in:
> a) helping to propose a VersioningFileProvider which stores attributes,
> based on the developments you already made.
> is proposing a vocabulary going beyond DC as pages can be
> speaking about a person, a product, etc. etc.
>     I think the metadata properties should be configurable based on a page
> type (the interwiki code corresponding to the page family)
> b) comparing my developments for CK editor with latest JSPWiki incarnation
> to describe what is in there, what I have tried, what remains to be solved
> c) contribute to a solution (to be invented together!) for storing
> references, scopes and linked properties within the wiki page text (and
> editable in CK: a.k. well represented in XHTML)

Before you jump too far into attempting to describe person, product,
etc. using some new methodology, consider there have been hundreds
of projects in a number of fields that have attempted the same thing,
not to mention all the Ph.D. projects out there that've never got much
visibility. I'd recommend reading up a bit in digital library texts about
Faceted Classification, as I'd avoid re-creating what sounds almost
like an enumerated classification system, very old-school librarian.
Any data/metadata classification system requires a great deal of effort
to create and maintain, so if in your experience people have no
patience with wikitext markup they're not likely to spend a lot of effort
on a classification system unless they're required to.

Some ideas anyway, and I've run out of time. I always run out of time...


View raw message