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

[Pierre R. <Pie...@sb...>]

I think modeling 1:n and n:m relationships is not really a problem as far as your relations (or tables) hold concepts (or objects) easily implementable as pages. The problem comes when you don't want to make them pages because it make not much sense.

I think modeling and create forms for:

-1 page to n properties is easy (arraymap)
-1 page to n pages is also easy (arraymap again)
-n pages to m pages is also easy (arraymap)
-1 page to n "complex records" (not a page) is harder (SIO and multiple form)
-1 page to n "complex records" to n "complex record" is not possible...

My data structure is an example of 1 page to n "complex records" to n "complex records"  but I had to make it 1 page to n page to n "complex record" (SIO) to keep the relationship between the first "complex records" and the second. I could not find another way. The main limitation I faced is that there is no way to create a multi-level form creating the link between the second and the third level.

You should write an article in the SMW wiki about your technique...

Pierre

> -----Original Message-----
> From: Justin Preece [mailto:pr...@sc...]
> Sent: Monday, August 22, 2011 3:03 PM
> To: sem...@li...
> Subject: 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
> > <Pie...@sb...>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
> >>
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and the
> tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Semediawiki-user mailing list
> Sem...@li...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user