From: Pierre R. <Pie...@sb...> - 2011-08-17 14:21:20
|
Hi, How can I build a two level 1:N structure? Here is an example of what I want to build: I want to be able to store info about "books", their "chapters" and each "chapter sections". There can be many "chapters" per "book" and many "chapters sections" by "chapters". How should I design my templates and forms? I'm thinking about three templates: "book", "chapter" and "chapter section". Or should it be a kind of nested template structure because the "chapter sections" should not exist without "chapters"? How do I design the form? I know I can add "multiple" to the "chapter" and "chapter section" templates to be able to add many of them in the form but do I have to and can I nest <for template> tags to be able add many "chapter section" in the "chapter" form? Thanks, Pierre |
From: Pierre R. <Pie...@sb...> - 2011-08-17 15:16:51
|
One constraint I forgot to mention is that I don't want separate pages for "chapters" and "chapter section". I want everything to display in the same "book" page and to be able to edit everything in the same "book" form... >From what I understand up to now is that if I create three separate templates and if I create three non-nested forms in the "book" form 1) I kind of lose the possibility to create the "Has chapter" and "Has section" relationships (based on the ) 2) It would be possible to create "chapter sections" without creating the parent "chapter" which are two undesired behaviors. I think I really need nested templates and nested forms? > -----Original Message----- > From: Pierre Racine [mailto:Pie...@sb...] > Sent: Wednesday, August 17, 2011 10:21 AM > To: sem...@li... > Subject: [Semediawiki-user] How to build a multi-level 1:n data structure? > > Hi, > > How can I build a two level 1:N structure? Here is an example of what I want to > build: I want to be able to store info about "books", their "chapters" and each > "chapter sections". There can be many "chapters" per "book" and many > "chapters sections" by "chapters". How should I design my templates and forms? > > I'm thinking about three templates: "book", "chapter" and "chapter section". Or > should it be a kind of nested template structure because the "chapter sections" > should not exist without "chapters"? > > How do I design the form? I know I can add "multiple" to the "chapter" and > "chapter section" templates to be able to add many of them in the form but do I > have to and can I nest <for template> tags to be able add many "chapter > section" in the "chapter" form? > > Thanks, > > Pierre > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user > administration capabilities and model configuration. Take the hassle out of > deploying and managing Subversion and the tools developers use with it. > http://p.sf.net/sfu/wandisco-d2d-2 > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user |
From: Yaron K. <ya...@wi...> - 2011-08-17 15:42:31
|
Hi Pierre, The Semantic Forms system can support a two-dimensional table of information on a page, using a multiple-instance template, but not a three-dimensional table. (Cube?) So the sort of three-level structure you're talking about can be done with two page types, but not one. So you could have either separate pages for books and chapters, or separate pages for books and chapter sections - it depends on which you think makes more sense. -Yaron On Wed, Aug 17, 2011 at 11:16 AM, Pierre Racine <Pie...@sb... > wrote: > One constraint I forgot to mention is that I don't want separate pages for > "chapters" and "chapter section". I want everything to display in the same > "book" page and to be able to edit everything in the same "book" form... > > >From what I understand up to now is that if I create three separate > templates and if I create three non-nested forms in the "book" form 1) I > kind of lose the possibility to create the "Has chapter" and "Has section" > relationships (based on the ) 2) It would be possible to create "chapter > sections" without creating the parent "chapter" which are two undesired > behaviors. I think I really need nested templates and nested forms? > > > -----Original Message----- > > From: Pierre Racine [mailto:Pie...@sb...] > > Sent: Wednesday, August 17, 2011 10:21 AM > > To: sem...@li... > > Subject: [Semediawiki-user] How to build a multi-level 1:n data > structure? > > > > Hi, > > > > How can I build a two level 1:N structure? Here is an example of what I > want to > > build: I want to be able to store info about "books", their "chapters" > and each > > "chapter sections". There can be many "chapters" per "book" and many > > "chapters sections" by "chapters". How should I design my templates and > forms? > > > > I'm thinking about three templates: "book", "chapter" and "chapter > section". Or > > should it be a kind of nested template structure because the "chapter > sections" > > should not exist without "chapters"? > > > > How do I design the form? I know I can add "multiple" to the "chapter" > and > > "chapter section" templates to be able to add many of them in the form > but do I > > have to and can I nest <for template> tags to be able add many "chapter > > section" in the "chapter" form? > > > > Thanks, > > > > Pierre > > > > > ------------------------------------------------------------------------------ > > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user > > administration capabilities and model configuration. Take the hassle out > of > > deploying and managing Subversion and the tools developers use with it. > > http://p.sf.net/sfu/wandisco-d2d-2 > > _______________________________________________ > > Semediawiki-user mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Pierre R. <Pie...@sb...> - 2011-08-17 16:05:25
|
I am also looking at the record type: I could define "chapter section" as a record type but Semantic form does not seems to allow creating forms for records. I'm also looking at Semantic Internal Objects: in this case both "chapter" and "chapter section" would be internal objects. Right? Pierre > -----Original Message----- > From: ya...@gm... [mailto:ya...@gm...] On Behalf Of Yaron > Koren > Sent: Wednesday, August 17, 2011 11:42 AM > To: Pierre Racine > Cc: sem...@li... > Subject: Re: [Semediawiki-user] How to build a multi-level 1:n data structure? > > Hi Pierre, > > The Semantic Forms system can support a two-dimensional table of information > on a page, using a multiple-instance template, but not a three-dimensional > table. (Cube?) So the sort of three-level structure you're talking about can be > done with two page types, but not one. So you could have either separate pages > for books and chapters, or separate pages for books and chapter sections - it > depends on which you think makes more sense. > > -Yaron > > > On Wed, Aug 17, 2011 at 11:16 AM, Pierre Racine <Pie...@sb...> > wrote: > > > One constraint I forgot to mention is that I don't want separate pages > for "chapters" and "chapter section". I want everything to display in the same > "book" page and to be able to edit everything in the same "book" form... > > >From what I understand up to now is that if I create three separate > templates and if I create three non-nested forms in the "book" form 1) I kind of > lose the possibility to create the "Has chapter" and "Has section" relationships > (based on the ) 2) It would be possible to create "chapter sections" without > creating the parent "chapter" which are two undesired behaviors. I think I really > need nested templates and nested forms? > > > > -----Original Message----- > > From: Pierre Racine [mailto:Pie...@sb...] > > Sent: Wednesday, August 17, 2011 10:21 AM > > To: sem...@li... > > Subject: [Semediawiki-user] How to build a multi-level 1:n data > structure? > > > > Hi, > > > > How can I build a two level 1:N structure? Here is an example of what > I want to > > build: I want to be able to store info about "books", their "chapters" > and each > > "chapter sections". There can be many "chapters" per "book" and > many > > "chapters sections" by "chapters". How should I design my templates > and forms? > > > > I'm thinking about three templates: "book", "chapter" and "chapter > section". Or > > should it be a kind of nested template structure because the "chapter > sections" > > should not exist without "chapters"? > > > > How do I design the form? I know I can add "multiple" to the "chapter" > and > > "chapter section" templates to be able to add many of them in the > form but do I > > have to and can I nest <for template> tags to be able add many > "chapter > > section" in the "chapter" form? > > > > Thanks, > > > > Pierre > > > > ------------------------------------------------------------------------------ > > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user > > administration capabilities and model configuration. Take the hassle > out of > > deploying and managing Subversion and the tools developers use with > it. > > http://p.sf.net/sfu/wandisco-d2d-2 > > _______________________________________________ > > Semediawiki-user mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > > > > > -- > WikiWorks * MediaWiki Consulting * http://wikiworks.com |
From: Yaron K. <ya...@wi...> - 2011-08-17 16:32:09
|
Hi, Yes, I forgot to mention Semantic Internal Objects - that's what I strongly recommend using. Like Semantic Forms, it can support a two-dimensional table, but not a three-dimensional one. You could use records too, but I think SIO is the better solution. Records, too, would only support a 2-D table. -Yaron On Wed, Aug 17, 2011 at 12:05 PM, Pierre Racine <Pie...@sb... > wrote: > I am also looking at the record type: I could define "chapter section" as a > record type but Semantic form does not seems to allow creating forms for > records. > > I'm also looking at Semantic Internal Objects: in this case both "chapter" > and "chapter section" would be internal objects. Right? > > Pierre > > > -----Original Message----- > > From: ya...@gm... [mailto:ya...@gm...] On Behalf Of Yaron > > Koren > > Sent: Wednesday, August 17, 2011 11:42 AM > > To: Pierre Racine > > Cc: sem...@li... > > Subject: Re: [Semediawiki-user] How to build a multi-level 1:n data > structure? > > > > Hi Pierre, > > > > The Semantic Forms system can support a two-dimensional table of > information > > on a page, using a multiple-instance template, but not a > three-dimensional > > table. (Cube?) So the sort of three-level structure you're talking about > can be > > done with two page types, but not one. So you could have either separate > pages > > for books and chapters, or separate pages for books and chapter sections > - it > > depends on which you think makes more sense. > > > > -Yaron > > > > > > On Wed, Aug 17, 2011 at 11:16 AM, Pierre Racine < > Pie...@sb...> > > wrote: > > > > > > One constraint I forgot to mention is that I don't want separate > pages > > for "chapters" and "chapter section". I want everything to display in the > same > > "book" page and to be able to edit everything in the same "book" form... > > > > >From what I understand up to now is that if I create three > separate > > templates and if I create three non-nested forms in the "book" form 1) I > kind of > > lose the possibility to create the "Has chapter" and "Has section" > relationships > > (based on the ) 2) It would be possible to create "chapter sections" > without > > creating the parent "chapter" which are two undesired behaviors. I think > I really > > need nested templates and nested forms? > > > > > > > -----Original Message----- > > > From: Pierre Racine [mailto:Pie...@sb...] > > > Sent: Wednesday, August 17, 2011 10:21 AM > > > To: sem...@li... > > > Subject: [Semediawiki-user] How to build a multi-level 1:n data > > structure? > > > > > > Hi, > > > > > > How can I build a two level 1:N structure? Here is an example of > what > > I want to > > > build: I want to be able to store info about "books", their > "chapters" > > and each > > > "chapter sections". There can be many "chapters" per "book" and > > many > > > "chapters sections" by "chapters". How should I design my > templates > > and forms? > > > > > > I'm thinking about three templates: "book", "chapter" and > "chapter > > section". Or > > > should it be a kind of nested template structure because the > "chapter > > sections" > > > should not exist without "chapters"? > > > > > > How do I design the form? I know I can add "multiple" to the > "chapter" > > and > > > "chapter section" templates to be able to add many of them in the > > form but do I > > > have to and can I nest <for template> tags to be able add many > > "chapter > > > section" in the "chapter" form? > > > > > > Thanks, > > > > > > Pierre > > > > > > > ------------------------------------------------------------------------------ > > > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > > user > > > administration capabilities and model configuration. Take the > hassle > > out of > > > deploying and managing Subversion and the tools developers use > with > > it. > > > http://p.sf.net/sfu/wandisco-d2d-2 > > > _______________________________________________ > > > Semediawiki-user mailing list > > > Sem...@li... > > > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > > > > ------------------------------------------------------------------------------ > > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > > user administration capabilities and model configuration. Take > > the hassle out of deploying and managing Subversion and the > > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > > _______________________________________________ > > Semediawiki-user mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > > > > > > > > > > > -- > > WikiWorks * MediaWiki Consulting * http://wikiworks.com > > > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Pierre R. <Pie...@sb...> - 2011-08-18 19:31:44
|
> Yes, I forgot to mention Semantic Internal Objects - that's what I strongly > recommend using. Like Semantic Forms, it can support a two-dimensional table, > but not a three-dimensional one. Do you mean it is still not possible to store the three level of information in the same page using Semantic Internal Objects? I'm now working on a solution storing books and chapters in their own pages and sections as SIO of chapters. I try to display all the information about a book its chapters and their sections in the book template using a two level query (the first level list the chapters using the Book42pschaptertemplate and the second one (part of the template) list the sections of each chapters) but at the end of each section query I get an unexpected warning saying: The part "|Chap 1 of Book 3" of the query was not understood. Results might not be as expected. The part "]]" of the query was not understood. Results might not be as expected. You can see the warning on the second query (Query 2: All the chapters informations using a template (doing itself a query)) in this page: http://pedrotodo.referata.com/wiki/Book_3 The template for book is here: http://pedrotodo.referata.com/wiki/Template:Book42ps and the template for each chapter is here: http://pedrotodo.referata.com/wiki/Template:Book42pschaptertemplate A syntax error somewhere in my templates or a bug? > You could use records too, but I think SIO is the better solution. Records, too, > would only support a 2-D table. How does Semantic Form handle records? Only one field for all the record's field or it is possible to create one field per record's field? Thanks, Pierre |
From: Yaron K. <ya...@wi...> - 2011-08-18 23:21:54
|
Hi Pierre, 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. 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. :) 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. -Yaron On Thu, Aug 18, 2011 at 3:31 PM, Pierre Racine <Pie...@sb...>wrote: > > Yes, I forgot to mention Semantic Internal Objects - that's what I > strongly > > recommend using. Like Semantic Forms, it can support a two-dimensional > table, > > but not a three-dimensional one. > > Do you mean it is still not possible to store the three level of > information in the same page using Semantic Internal Objects? > > I'm now working on a solution storing books and chapters in their own pages > and sections as SIO of chapters. I try to display all the information about > a book its chapters and their sections in the book template using a two > level query (the first level list the chapters using the > Book42pschaptertemplate and the second one (part of the template) list the > sections of each chapters) but at the end of each section query I get an > unexpected warning saying: > > The part "|Chap 1 of Book 3" of the query was not understood. Results might > not be as expected. > The part "]]" of the query was not understood. Results might not be as > expected. > > You can see the warning on the second query (Query 2: All the chapters > informations using a template (doing itself a query)) in this page: > > http://pedrotodo.referata.com/wiki/Book_3 > > The template for book is here: > http://pedrotodo.referata.com/wiki/Template:Book42ps and the template for > each chapter is here: > http://pedrotodo.referata.com/wiki/Template:Book42pschaptertemplate > > A syntax error somewhere in my templates or a bug? > > > You could use records too, but I think SIO is the better solution. > Records, too, > > would only support a 2-D table. > > How does Semantic Form handle records? Only one field for all the record's > field or it is possible to create one field per record's field? > > Thanks, > > Pierre > > > > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Pierre R. <Pie...@sb...> - 2011-08-19 18:55:35
|
> 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 |
From: Yaron K. <ya...@wi...> - 2011-08-19 19:39:13
|
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 > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Justin P. <pr...@sc...> - 2011-08-22 19:03:29
|
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 >> >> > > > |
From: Pierre R. <Pie...@sb...> - 2011-08-22 20:34:01
|
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 |
From: Robert M. <mra...@gm...> - 2011-08-22 23:22:58
|
Yes please! (write the article) On Mon, Aug 22, 2011 at 3:33 PM, Pierre Racine <Pie...@sb...> wrote: > 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 > > ------------------------------------------------------------------------------ > 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 > |