Re: [Semediawiki-user] How to build a multi-level 1:n data
structure?

Just to chime in, I have experience using sub-pages to simulate
relational data structures (1:n, n:n) in SMW with SF:
[1:n]
I generally use the page names as keys, and my "child" tables are all
sub-pages with a standardized page title suffix (i.e. Page_1/Child_Data,
Page_2/Child_Data, etc.) and a single Page prop relating them back to
their parent. Next, I place a multi-instance template on the sub-page,
mimicking each "row" of subsidiary data. If my "rows" of child data have
multiple "columns", I place an SIO declaration in the multi-instance
template to bind each "row"/SIO together.
[n:n]
For sibling relationships, you can store Page properties in an #arraymap
and semantically relate any page to any number of other pages (i.e.
Article 1 relates to Reference Articles A & B. Articles 2 & 3 relate to
Reference Articles A, C & D.). You can make the relationship nominally
uni-directional; that is, pages of type A show their relationship(s) to
pages of type B via queried links, but in reverse have type B hold the
prop array of type A pages.
As to the effectiveness of all these "meta-data structure"
acrobatics...that's another matter. My #ask and #show querying is fine,
and I can easily auto-generate form links and page links from my parent
page to the sub-pages and vice-versa, but my users will have to jump
around a bit to enter and edit data. On the plus-side, I am able to
bring a bit of data mgmt rigor to my wiki. NOTE: I do have to lock down
my page-naming scheme to preserve integrity. That won't work for
everyone's implementation.
** WARNING, PONTIFICATION ALERT ** Philosophically, SMW and SF seem to
occupy that fuzzy space between "structured-data web app" and
"free-wheeling wiki"...and that means, IMO, that both hard-core data
description/preservation types and long-tail, organic, "free-the-data"
folks both have to compromise to get the most out of the platform. Make
your SMW/SF wiki too much like a traditional CRUD web app with an RDB
back-end and you've missed the point (plus, you'll be frustrated at the
lack of full programmatic control over data structure and
functionality). Conversely, try to corral a bunch of random SMW property
annotations into a useful data set over which to inference, and you
won't get much out of it either, semantically-speaking, until you have a
lot of aggregated data on a lot of wiki pages. Somewhere between these
two extremes, however, there is utility to be had.
- Justin
Side note for the curious: I take these [1:n] and [n:n] approaches
outlined above, instead of using nested templates and/or edit-in-place
features, b/c I like have more control over the layout of multi-instance
data, need to use header tabs, and am working at a data scale that needs
normalization to perform well.
On 08/19/2011 12:39 PM, Yaron Koren wrote:
> Hi,
>
> For page names, if there's no obvious page name, I'd recommend using
> subpages, i.e. slashes - for example, "Foo/Chapter 1/Section 2".
>
> It's true that the fact that in SMW page names are used as IDs, instead of
> having separate IDs, can lead to problems - for that, I recommend the
> Replace Text extension, which was actually created in large part to combat
> that problem:
>
> http://www.mediawiki.org/wiki/Extension:Replace_Text
>
> -Yaron
>
> On Fri, Aug 19, 2011 at 2:55 PM, Pierre Racine
> <Pierre.Racine@...>wrote:
>
>
>>> Yes, it's not possible to store three levels of info on one page using
>>>
>> SIO - and I'm
>>
>>> not planning to ever add such a feature in.
>>>
>> What I have now is a unique three part form using three templates storing
>> chapters and sections as SIO in the book page. I had to add a Chapter field
>> to the Section form in order to store the title of the chapter this section
>> belongs to. The problem is: if the chapter title change, the link is broken
>> unless you also change the chapter title in the section. It acts as a
>> foreign key that we, unfortunately, have to update manually.
>>
>> I am basically trying to implement a relational database schema in Semantic
>> Mediawiki. The problem is I don't want every relation tables to become a
>> page even if it make sense that some do. I see this as a true limitation of
>> Semantic Mediawiki.
>>
>> Some very textual objects like books, authors or articles make sense as
>> pages but other objects very much linked and unique to the first objects are
>> hard to imagine as pages. There is also the problem of page names. In my
>> case chapter's pages could be named "Chapter 1 of book Foo" but it becomes
>> awkward for sections: "Section 2 of Chapter 1 of book Foo". In the end you
>> have way to many pages and you have to maintain the foreign keys by hand
>> because the keys are the pages' names. If you change the name of the page
>> the key is broken. If you store everything as SIOs to keep all related info
>> together you have to create foreign keys (each Section has to store the
>> chapter they belong to) and also maintain them. In the case of pages you can
>> leave a redirect but this does not work for SIO.
>>
>> I think to be fully able to easily implement complex relational database
>> schema without implementing everything as pages we need 1) nestable SIO and
>> 2) nestable forms. Nestable SIO (like XML nested tags) make explicit the
>> link between two nested SIO (like a SIO stored in a page is explicitly
>> linked to this page) and nested forms make possible to enter data for these
>> nested SIOs... But that might break too much the wiki philosophy of
>> everything is text (and pages).
>>
>>
>>> I don't know what's wrong in your example, but my guess is that it's a
>>> malformed query somewhere, and not an SMW bug. I hope so, anyway. :)
>>>
>> The error was that the first parameter passed to the template format is not
>> just the text of the title of the page like "This is the title of the page"
>> but the entire link with the beginning and ending brackets like "[[:This is
>> the title of the page|This is the title of the page]]". Passing this to the
>> ask# page selector was causing the warning. I fixed it by replacing {{{1}}}
>> with {{#sub:{{#explode:{{{1}}}|#|0}}|3}} and everything works like a charm.
>>
>>
>>> I'm pretty sure SF can handle the record type, but I've never tried it
>>>
>> directly, so I
>>
>>> don't know how it would work exactly.
>>>
>> It does but it does not display three field for a three part record. It
>> display a single field and you have to separate the values with a comma.
>>
>> Pierre
>>
>>
>
>
>