[Libreplanet-dev] smw woes

[Peter]

So I thought using properties would allow us to simulate a virtual database.

For example, we have users who will join and leave groups, projects, 
campaigns, meetings, and just about anything. It would be handy to record a 
user's movements in a log page:

Member    StartDate     Status      EndDate
Foo           5 May          Active
Bar           3 May          Retired      7 May
Baz          7 Feb           Probation

with the properties:

Member: String (User namespace)
StartDate: date
Status: String (enumerated: Other, Active,Inactive,Probation,Retired,...)
EndDate: date

An entry template assigns each property to a field and a Membership form sets 
the template as recurring. This allows a user to 'form edit' the page and 
add/remove/modify their entry (or anyone's).

This works perfectly, you see a page table and factbox with the proper 
properties and values.

Now we go to another page to list these entries, using #ask, and we end up 
with:

Member    StartDate     Status      EndDate
Foo           5 May          Active       7 May
Bar           3 May          Retired
Baz          7 Feb           Probation

which is wrong, and also, you cannot sort the table using the header icons. 
Foo did not leave on the 7 May, but Bar did. The reason this doesn't work is 
that smw creates a single row of properties _per page_, but lists each value 
vertically and independently of all other properties. So smw does not care 
that the 7 May is the second element in the EndDate, it lists it first 
because the first element (Foo's EndDate) is blank. The sort icons only sorts 
pages, a property's value list is not sortable.

The date property itself is problematic because it does not allow a NULL 
value; 0 (zero) is set to 1 BC. However, our member form must include the 
EndDate so users can designate when they left. Clearly, the only time (excuse 
the pun) the dates will line up is when they're all filled in.

Finally, you can only use Special:addData/Member/SomeLogPage to a redlink 
page, once the page has been created addData will generate an error message. 
So we need to check whether the page exists in order to decide whether to 
include a #formlink add button to create and edit, or a normal link, to view 
and edit. This means we need the ParserFunction extension, which has the 
#ifexist to check if a page exists.

Right now I can implement registration, as described above, with two 
limitations:

1- You will always get both a redlink and create formlink. If you pick the 
wrong one, you will get an error (page exists), or the default edit page. 
This can be avoided using the ParseFunctions extension.

2- Including dates with blank (invalid) entries will seldom produce valid 
tables, so data mining logs will be tricky.

This implementation works with the navigation system, so it becomes part of 
the browsing experience. Registration pages are linked to and automatically 
created if they don't exist, so members simply create meeting, project, etc. 
pages and the first user will create the member page, while the others will 
simply add their entry.

Every membership page is categorized, so users can create an #ask list and use 
them as possible bookmarks.

Clearly, the semantic property is not suitable for database use because it is 
based on a page, not a value. Semantically, we're interested in pages related 
to a property, but datawise, we're interested in a property's value, not 
page. This means redefining what we mean when we say, 'Users can register 
with a project'. No longer does a user have a Member property, but rather, a 
page has that property with a user value.

Because smw is semantic, we have to be careful with our semantics, there is 
such an entity as a user:a person with an account; and a semantic user: all 
pages containing user properties. How well the semantic user emulates the 
real user will determine how well LP handles user activities. This means user 
properties represent specific user values on a page, rather than describing 
the user. 

So the Member property semantically relates a user value to a project page, 
rather than defining the user as a 'member of project x'. Similarly, the 
StartDate property relates to a project page chronologically, without 
identifying a user. Only through queries can we combine properties to 
'describe a user'.

This is where the Concept namespace makes sense. Since we can conceptualize a 
user having Member and StartDate properties, we can add this query to the 
Concept namespace. Now we have the concept of a user 'being a member of a 
page at some date'. This enables us to find all the pages the Member property 
has the user's name and the StartDate property, or 'what projects is the user 
a member and when?'

Unfortunately, the Concepts will fail if, for example, the EndDate property 
appears more than once on a page for different members. As shown above, the 
EndDate property does not relate its page values to other properties (how can 
it?) and so will return 7 May for the Member property value Foo, indeed, for 
all Member values on the page.


While the semantics might work well for describing free software ethics, such 
as the properties Use, Copy, Modify, and Distribute, which we can attach to 
programs and then identify those that are Copy::Free + Use::Free + 
Modify::Free + Distribute::Restricted, and compare them with other software 
with 'different ethical values', we can run into the same issues as EndDate 
where we use the Distribute property more than once on the same page for 
different programs.

The only solution I see is to use multi-valued properties. This is a property 
separated by ; such as 

Ethic:: CopyType; ModifyType; UseType; DistributeType;

where the XXType are semantic types, string or enumerated.

Now, whenever we assign an ethic property to software (or anything, actually), 
the ethic components are associated with the software, too. I have not yet 
tried this, but I hope smw will do the right thing and only list components 
related to the ethic property, and not do something like the EndDate example.

To summarize, I think forms are useful in helping users create and edit pages, 
but I don't think smw itself is suitable as a framework for a local group 
network wiki. The semantics is evidently tied to page content and not able to 
articulate group, member, and user entities as database tables or relations.

I am still keen to work on developing a navigable, form based, group oriented 
wiki because the ones similar to LP seem superficial, at first glance they're 
attractive, but there's no depth, or real thought to their design and 
construction. I know LP members can provide a wealth of social and ethical 
resources, but we can and should provide a wiki that enables them to do so in 
an easy and publically accessible way. Most of the current documents are 
inaccessible, despite being categorized. We can do better.

So I have been inactive on LP because the original design I had in mind won't 
work as expected, and I am unsure how to proceed. It has become clear to me 
that while we can use smw to show 'users are a member of', we cannot do this 
in a straight forward manner and it will conflict with document usage it was 
designed for. 

My problem is that I don't see how we can effectively use smw within the 
context of a local group network. To do so, we need to define what a local 
group network semantically means, and then assign properties, templates, 
forms, and concepts accordingly. The definitions, however, cannot be stated 
in wiki terms because that defines an implementation, not a concept. A group, 
for example, should not be defined as a page or namespace, but as people and 
area (for example). Relationships, too, need to be defined in a non-wiki way. 
Paradoxically, the defintions can be a document that has semantic value and 
is a candidate for smw, although its properties, templates, and forms may be 
unrelated to the properties it ultimately defines.

Any thoughts?

Regards,

Peter