[Phpwiki-talk] link schema enhancements

[Reini U. <ru...@x-...>]

Dan,
I saw in wikilens that you introduced a seperate category table,
and will (already) need a lot of more tables.

I thought for 1.3.12, while working on the SemanticWeb, that we could
simply enhance the link table with an additional optional column which
describes a link relationship.

The default would be "LinksTo",
for category this would be "CategoryOf", for other things it might be
"ClassOf", or any other, when properly handled by any plugin or lib or
InterWikiMap entry.

I also want to extend certain InterWikiMap entries to define such relations:
"PropertyOf", "SubClassOf", "isa", "has", where each of those relations
specifies the relation of the current page to the linked pagename.

ALTER TABLE $link_tbl ADD relation CHAR(15) NOT NULL DEFAULT "LinksTo"

The StructuredData might then be able to query the link table.

Metainformation about the links fort certain groups of pages can be
queried in a OWL fashion by some new format handlers.

I will setup a wikipage for this proposal.
  http://phpwiki.org/LinkRelationship

What I want:
* Enrich the links
* Easily define PageGroups (lists of pages)
* Use StructuredData (acdropdown - static js dropdowns)

PageGroups:

like "Status"
isa:List
   * Approved
   * Incorporated
   * Pending
   * Proposed
   * Rejected
and any list widget will just get "Status".
createWidget("status", "Status") will see that "Status" isa "List" and
calls the List() method of the Widget object, storing the result in the
relation "status".

As plugin like this: <?plugin Widget relation=page ?>
e.g.
AnyPage: <?plugin Widget status=Status ?>
The state of the Status in AnyPage will be internally stored as link,
AnyPage => status:Proposed.
To explicitly define some relation simply write status:Proposed, which
creates no widget.
  (db: linkfrom=AnyPage,linkto=Proposed,relation=status)
But maybe some special relations should be allowed create their widgets
automatically.
The page "isa:Relation" could define the behaviour if the relations.
each isa:<> must have a proper class definition.

AnyPage => statusWidget:Proposed
will display the widget and not the link, if
statusWidget => isa:Widget

So the relation (here statusWidget) should search for an internal class,
and then for an external pluginname to define its methods.
If no special class is found, it will search for a pagename, which may
define an isa:<class> link, where a new search or the parent <class> will
start.
Yet undefined is what will happen with multimethods (multiple isa: links
in a page). CLOS handles this just fine, but I'm not sure about our case
here, how to define precedence. The link table is not ordered.
And CLOS is method centric, we are unfortunately object centric, where
multiple inheritance is hard.

Categories are a bigger beast, being a container of multiple objects, with
its own properties (has:) and methods (search, display, edit, list).
I think my proposal will handle all this.

What I get:
* Every link relation is bound to a pagename, but not necessarily
  to a revision.
** So widget properties, categories and so on are self-describing and
  editable.
** Easily define complex relations and inheritance.
* Easily extendable to the InterWikiMap syntax: <moniker>:<pagename>
  where moniker describes a relationship.


-- 
Reini Urban
http://phpwiki.org/   http://xarch.tu-graz.ac.at/home/rurban/