[Phpwiki-talk] Re: link schema enhancements

[Dan F. <dfr...@wi...>]

Reini Urban wrote:

>Dan,
>  
>

First, let me say you should definitely *release* before pursuing any of 
this. We can't merge Phpwiki latest changes until it has a stable 
release. We are still on 1.3.9, and it's hurting us. For example, 
ALLOW_ANON_EDIT is busted and it was not obvious to me how to fix it.

Having said that ..

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

We have added some tables, correct. To be precise:

- page_urn, urn: these allow multiple rating widgets on a page 
("RateMania"). Users like this, although the markup for it ("<?plugin 
RateIt ..>") is too awkward for them right now.

- logging: we just added this in GalacticGopher for research purposes 
(what is the nature of the activity taking place?). GG is released on 
cs.wikilens.org (a new community) but not www.wikilens.org.

- category: relationship table since we took categories out of page 
text. We were sad to abandon the wiki way in this regard, but casual 
users didn't understand the in-page thing and would erase the category 
membership.

- chefmoz: a table to hold restaurant data for 'import' into a system 
with a Restaurant category.

>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"
>  
>

This seems link a decent change in theory. A few comments:

1. It will only address our 'category' table from above. That's okay, 
though. I can imagine using it for other important relationships we've 
not yet modeled in the database: buddy (we have "pending", "waiting", 
now "email", and "buddy"); list item. Thus, it seems useful to me.

2. It should be an int. Since it is specifically for performance and I 
know DBs can process an integer index much faster than a character one, 
it seems right to have it be an int which is a foreign key into a 
relation_type table.

>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.
>  
>

This I didn't understand. I don't see the meta-data anywhere, and I 
don't know what OWL is.

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

Okay.

>What I want:
>* Enrich the links
>  
>

?

>* Easily define PageGroups (lists of pages)
>  
>

This seems good. I want this as well, though interestingly for a 
different list than PageGroup.

>* Use StructuredData (acdropdown - static js dropdowns)
>  
>

How is acdropdown related to structured data? What is static dropdown?

>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".
>  
>

Not quite sure what these list widgets are that you're talking about and 
why they have these statuses. Example?

It looks almost like you're talking about a bug-tracking type of thing?

>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.
>  
>

I'm not sure when I'd use the Widget plugin. I'd like to avoid it if I 
could, I think. I'm also not sure about the statuses.

>The page "isa:Relation" could define the behaviour if the relations.
>each isa:<> must have a proper class definition.
>  
>

This is potentially good. Not sure what you're planning to apply the isa 
to yet.

>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.
>  
>

Sorry, I think I know CLOS (common Lisp, eh?), but I'm not sure what 
you're describing.

>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.
>  
>

Hmm.

>What I get:
>* Every link relation is bound to a pagename, but not necessarily
>  to a revision.
>  
>

In our case, I was pretty sure we wanted our structured data and 
category membership at least to be bound to a particular revision. This 
allows one to 'revert' a page back to its old category, for example.

>** So widget properties, categories and so on are self-describing and
>  editable.
>  
>

I like this sentence, but I don't understand how it follows from the 
previous.

>** Easily define complex relations and inheritance.
>  
>

We thought about inheritance for awhile for our categories (e.g., Book 
=> Fiction Book), and decided that normal users wouldn't understand it. 
We thought that what they usually really want is just subcategories 
(groupings).

That doesn't mean you don't have some other use case with categories in 
mind.

>* Easily extendable to the InterWikiMap syntax: <moniker>:<pagename>
>  where moniker describes a relationship.
>  
>

Hmm. Not sure about this. We decided to take all category information 
out of pages. It'd be painful to now put it back in somehow. I'm not 
entirely opposed, though. I'd just have to try to remember all the 
reasons we took it out in the first place.

Dan