[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Libreplanet-dev] smw woes
[Libreplanet-dev] smw woes
Fri, 29 May 2009 03:41:10 +0000
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)
Status: String (enumerated: Other, Active,Inactive,Probation,Retired,...)
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
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
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
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
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
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.
|[Prev in Thread]
||[Next in Thread]|
- [Libreplanet-dev] smw woes,