JeffDairiki

MeatballWiki | RecentChanges | Random Page | Indices | Categories

That's http://phpwiki.sourceforge.net/phpwiki/JeffDairiki

Thoughts on ModWiki

(Sorry this took so long...)

I like the latest proposal (v0.44) by LaurensPit. I do have a few remaining concerns, however. Some of these are rather vague (and I should probably research them further before anyone takes them too seriously), and others are more concrete. In order from the more specific to the more speculative:

InterWiki and mod_wiki

I think we need a way to include the InterWiki moniker as well (or even instead of) the InterWiki URL prefix. I have trouble imagining when an RSS client would find the URL prefix useful (when does it have to generate URLs for arbitrary pages on the host wiki?). The InterWiki moniker, on the other hand, could certainly be used when displaying UnifiedRecentChanges to identify the source wiki. E.g. consider this HTML bogo-template fragment:

   <a href="${item link}">${channel interwiki moniker}:${item title}</a>${item desription}

: I included the interwiki URL prefix because it was proposed to be included (I think even by you ;), and because I find it actually useful: I can update my InterMap automatically when syndicating an RSS feed. -- LaurensPit

: I might have typed the phrase "InterWiki prefix", but I'm pretty sure that I meant "InterWiki moniker". :-) ("Prefix", you must admit, is somewhat ambiguous.) I have no complaints about including both the moniker and the URL prefix --- they're certainly both useful meta-data about a wiki. I mostly wanted to make the point that, to me, for UnifiedRecentChanges purposes, the moniker is the more crucial of the two. --JeffDairiki

: My english is not that well that I understood what you meant by moniker :| I understand now, I'll add it. Any preference/suggestion for the way to describe this data?

: To identify the source wiki in UnifiedRecentChanges wouldn't you use the value from rdf:RDF/rss:channel/rss:link ?

: (You mean rss:title rather than rss:link, I think.) Yes, you could use that. However I imagine a compact UnifiedRecentChanges display that would list pages simply as, e.g. MeatBall:JeffDairiki, rather than displaying the source wiki and page name separately. See [1] (with CSS/2 browser) for an example of what I mean.

Side-thought: The syntax of the InterWiki prefix should be expanded. Sometimes one can not form the desired URLs simply by prefixing the local part of the InterWiki name. In the latest PhpWiki if the InterWiki "prefix" includes the substring %s, the local part of the InterWiki name is substituted for the %s, rather than being appended to the prefix. This allows the InterWiki map entry:

  RFC http://www.faqs.org/rfcs/rfc%s.html

(The %s syntax could, perhaps, be improved upon.)

Of course, if the InterWiki prefix is not part of mod_wiki, then there is no reason for there to be any sort of universal agreement as to the syntax of the "prefixes", since their use would be local to each wiki.

: Expansion of the syntax of the InterWiki prefix is useful indeed. In OpenWiki I've already got this feature (mainly because I needed to point to RFC's), using $1. I've also started to call it something different (InterLinks?), because most of my InterMap actally contains non-wiki stuff.

: I think it's best if we discuss this issue further at InterWiki and/or Wiki:InterWiki. -- LaurensPit

: Yes, of course. I only brought it up here, since it really only becomes an issue if/when the InterWiki prefix is included in mod_wiki. Until then, there's no need for standardization --- each wiki can use whatever magic syntax it likes. -- JeffDairiki

: Just thought I would mention that TWiki also has extended the InterWiki syntax - it uses $page as the marker for the WikiWord. -- RichardDonkin

Item rdf:about URIs

First, to reiterate what Laurens has said: the URIs in the rdf:about attributes of <item/>s serve solely as unique identifiers for those <item/>s. They need not be valid URLs. As Laurens said, they must be unique within an RSS channel. More than that however, they should be globally unique. If two <item/>s (from different RSS channels) have the same rdf:about URI, it means that they refer to the same RDF "object".

<Item>s are about specific page revisions. Since mod_wiki <item>s can (and in most cases will) contain information pertaining to a specific revisions of a page (e.g. wiki:status, wiki:importance, wiki:version), it seems the <item>s rdf:about URIs should also be unique to a specific wiki page revision.

Advantages to this:

If an UnifiedRecentChanges aggregator sees two <item>s with the same URI, it can safely assume they apply to the same revision.
It allows information about multiple revisions of the same page to be included in a single RSS channel. This allows the productions of RSS page histories. It also allows RecentChanges (or RecentEdits?) listings which list all revisions to each page, not just the most recent. (That all wikis don't support these sorts of listings doesn't justify the view that mod_wiki shouldn't support them.)
It seems to me (an admittedly non-expert) to be more in keeping with the RDF way.

Disadvantages:

Versioning is un-wiki.

: Wikis are used by different groups for different things. Often versioning is important (e.g. private wikis used for collaborative documentation). One could certainly make the claim those uses are deviant, and that those are sites therefor not true wikis --- nevertheless, RSS is still potentially important in those uses, and I see no need to exclude their consideration from mod_wiki.

I think you said it perfectly, it's no different from what I said/think. All the advantages can be had with mod_wiki. The disadvantage is not really that, because you can only have that disadvantage when you say the <item>s rdf:about URIs must be unique to a specific wiki page revision instead of should be unique. -- LaurensPit

Actually, I am proposing that the rdf:about URIs must be unique to a specific page revision. The first advantage I listed above relies on this (since, if the URIs only should be unique, then an aggregator can not reliably use the rdf:about URIs for duplicate detection.) The "disadvantage" I have listed is really only a philosophical one, therefore it has little bearing on must vs should.

I would like to reitereate, just in case there is still some confusion, that unique URI generation is not a problem, even for a wiki which only keeps the most recent version of each page. The only requirement is that the wiki has some way (e.g. revision number, modification time, or even a hash of the page contents) to uniquely identify the current revision. The URI need not be a valid URL. Something like

  http://www.usemod.com/cgi-bin/mb.pl?action=browse&id=JeffDairiki&revision=6

is perfectly acceptable, even if revision 6 is no longer available, or even if the ?revision=6 CGI query argument is not supported by the wiki. The only requirement is that the mapping between the triple (wiki,page,revision) and the item rdf:about URI be (globally) one to one.

: I added a datestamp: <rdf:li rdf:resource="http://127.0.0.1/cgi-bin/wiki.bat/WikiSandBox#20011126221121" /> -- JürgenHermann

: Yes! That works.

Wiki:importance and wiki:version

As proposed in v0.44, the values of the properties wiki:importance and wiki:version are enumerations. (I.e. they are limited to the selection of one (english) word from a predefined set.) As I understand it, these values are not intended for machine, not human consumption.

My (weak) understanding of RDF leads me to suspect that the values for these properties ought to instead be references to objects (i.e. URIs to be defined by mod_wiki). E.g.

   <wiki:importance resource="http://purl.org/rss/1.0/modules/wiki/importance#major"/>

instead of

   <wiki:importance>major</wiki:importance>

Perhaps cleaner would be:

   <wiki:flag resource="http://purl.org/rss/1.0/modules/wiki/importance#major"/>
   <wiki:flag resource="http://purl.org/rss/1.0/modules/wiki/status#updated"/>

   (perhaps wiki:status instead of wiki:flag would be better?)

instead of

   <wiki:importance>major</wiki:importance>
   <wiki:status>updated</wiki:status>

I guess these syntaxes might not work so well with legacy RSS parsers. Then again: who cares?

: See <sy:updatePeriod> at http://groups.yahoo.com/group/rss-dev/files/Modules/Standard/mod_syndication.html, which is an official RSS module. And see http://dublincore.org/documents/2000/07/11/dcmes-qualifiers/, which is like your suggestion. I like the 1st syntax, don't like the wiki:flag syntax (explained below) -- LaurensPit

: Okay. As I said, this was one of my more vague concerns. I'm convinced. Your way is good.

: With the 1st syntax, I was refering to the one with <wiki:importance resource="http://purl.org/rss/1.0/modules/wiki/importance#major"/>. I don't see the clear advantage when compared to the <wiki:importance>major<wiki:importance></tt> syntax though, it's just a feeling. -- lp

: Yes, I think we agree. For practical purposes your original <wiki:importance>major</wiki:importance> syntax works fine. My first proposal above might be more "pure RDF" in some IvoryTower? sort of way --- maybe. Your syntax is probably easier to deal with when using current (not so RDF aware) RSS or XML parsers. If we all had real RDF parsers (and I don't, right now) my suggestion might lead to more concise code. This evening, my feeling is that consideration of backwards compatibility tips the balance in favor of your v0.44 syntax. --JeffDairiki

Diffs and Page History

In mod_wiki, v0.44, both the wiki:diff and wiki:history properties give URLs to pages which give meta-information about wiki pages. As such, their function is quite similar, and it might be nice to unify the syntax.

Also, 'Diff' is fairly ambiguous. What versions are to be diffed? Major diff? Minor diff? Author diff? Diff to most recent, or to specified version? It would be nice if the source wiki could specify a bit more about what sort of diff it is in the RSS. It might also be nice if links to several different sorts of diffs could be provided.

: At most wiki's you'll see a link labeled 'diff', which is ambiguous, but also seems to be ok as nobody bothered to label it more explicitely. However, should you want to be more explicit, we could have something like:

  <wiki:diff rdf:parseType="Resource">
    <wiki:diffType rdf:resource="http://purl.org/rss/1.0/modules/wiki#MajorDiff"/>
    <rdf:value rdf:resource="http://www.mysite.com/?SandBox&a=diff"/>
  </wiki:diff>

Finally, some wikis may want to offer other sorts of links to page meta-information. (Though, right now, I honestly can't imagine what --- so maybe you should ignore this paragraph.)

My 'button' syntax provides a solution to this. (Though I readily admit that 'button' is a bad name, and I think my original proposal is not quite valid RDF.) Here it is again in slightly modified form. (I'm still not happy with the name. Has anybody got a better idea?)

Some possible syntaxes:

Unabbreviated:

  <rss:item rdf:about="...">
    ...
    <wiki:metapage>
      <rdf:Description>
         <wiki:name>Major Diff</wiki:name>
         <wiki:link>http://...</wiki:link>
      </rdf:Description>
    </wiki:metapage>
    ...
  </rss:item>

Fully abbreviated. This, I think, has the property that most non-RDF-aware RSS parsers will just ignore the wiki:metapage property altogether:

  <rss:item rdf:about="...">
    ...
    <wiki:metapage wiki:name="Major Diff"
                   wiki:link="http://..."/>
    ...
  </rss:item>

Mixed abbreviation (others are possible). I think this has the property that non-RDF-aware RSS parsers will see just the URL; essentially: "wiki:metapage='http://...'".

  <rss:item rdf:about="...">
    ...
    <wiki:metapage>
      <rdf:Description wiki:name="Major Diff">
         <wiki:link>http://...</wiki:link>
      </rdf:Description>
    </wiki:metapage>
    ...
  </rss:item>

: I have several problems with this kind of syntax: it's too generalized: I do not want to blindly generate 'buttons' just because they happen to be defined in an RSS document, I only want to show specific ones. I want those specific ones to have the exact same label for all RSS documents that I syndicate (so as not to unnecessarily confuse users), therefor I will ignore wiki:name. I don't know what kind of metapage I'm dealing with. This could be solved by replacing wiki:name by say wiki:metapageType, but that means you'd have to define the possible types upfront, in which case you might as well have wiki:diff, wiki:history, etc. elements. It's also possible that in the future one would want to describe/expand wiki:diff further in a much different way than wiki:history. For example, take my example above where wiki:diffType is added to the wiki:diff element. You can not do such a thing had you had a wiki:metapage element. You could define a general wiki:metapageType, but the set of possible values would contain mixed types. Generally, at this level of data I think it's not correct to use metadata as part of your data, as (as Sunir also mentioned in ModWikiDiscussion) you'd require a separate grammar to parse it. Being explicit about the data you're presenting is what I prefer. -- LaurensPit

: Good points. Okay, I withdraw this section, too. :-)

I guess I'm not real happy with any of those choices. Mostly on account of how I think they're going to interact with non-RDF-aware RSS parsers (e.g. most of the RSS parsers in current use.) Which brings up another point:

Compatibility with "Legacy Parsers"

We need to test the proposed syntaxes (especially the "clever" ones, like those suggested above, and the one for dc:contributor in mod_wiki v0.44) against existing popular RSS parsers to see how they fare.

There is also the issue of how much effort we want to make to try to be compatible with the non-RDF versions of RSS (e.g. 0.9x).

: I don't care about 0.9x. ;) I do care about RSS 1.0 parsers out there. -- lp

CategoryHomePage