From: Rolf L. [RIL] <rol...@ri...> - 2009-01-26 15:13:39
|
Rolf Lampa [RIL] skrev: > > #1. Book: standard Semantic Form behavior. > #2. Author: autocreated. > #3. BookAuthorLink: autocreated. > Actually only step #3 (BookAuthorLink) needs the (final) titles of the Book title AND the Author title, for the single links it holds (again, if titles are calculated according to formula). // Rolf Lampa >> -Yaron >> >> On Mon, Jan 26, 2009 at 9:54 AM, Rolf Lampa [RIL] >> <rol...@ri... <mailto:rol...@ri...>> wrote: >> >> For some reason a lot of strange extra slashes were inserted in >> the post >> by the thunderbird client (especially in the "{{{info|" sections). >> Please disregard them. >> >> // Rolf >> >> >> >> Yaron Koren skrev: >> > Hi, >> > >> > I don't understand - of the three page types, which one(s) are >> getting >> > created automatically? >> > >> > -Yaron >> > >> > On Mon, Jan 26, 2009 at 9:02 AM, Rolf Lampa [RIL] >> > <rol...@ri... <mailto:rol...@ri...> >> <mailto:rol...@ri... <mailto:rol...@ri...>>> wrote: >> > >> > Hi, >> > >> > Since a n..n relation essentially is made out of two 1..n >> > relations (seen from the "middle class") pointing at two end >> > classes, and a 1..n relation shouldn't be impossible to fix (see >> > the rest of the post below) don't you think your Semantic Form >> > could simply implement what Dan suggested, namely 1..n >> relations? >> > >> > If a user wants to make a n..n relation he only has to define it >> > in two steps instead of one, like so (I'll describe this in >> three >> > different levels of detail below, first the simplest form): >> > >> > #1. Standard Form:Book definitions. >> > #2. A "createpage variant" of a subform for Author (if not >> exist) >> > #3. A "createpage variant" of a subform for BookAuthorLink >> (if not >> > exist) >> > >> > Press submit and voila!, a page triple is created/assined! :) >> > Note that the steps 2 and 3 above are actually identical, they >> > only deal with two different objects (pages). Note also that >> 1..1 >> > relations as well as 1..n should be possible by implication (due >> > to the ability to assign a property in the newly created >> page/object). >> > >> > Below the three steps above again, but now in more detail: >> > >> > #1. Form definitions for a book as usual. only make sure >> that the >> > title is somehow stored in a parameter or variable, since it >> will >> > be needed for linking to the (this) book from the autocreated >> > pages lower down on this form. >> > >> > {{#vardefine: BookTitle | from field name, template or >> form-info's >> > formula }} >> > >> > #2. Create an Author, no links assigned. >> > >> > {{{createpage|Author|page title={{{First name}}} {{{Last >> name}}} >> > | First Name=Yaron >> > | Last Name=Koren >> > }}} >> > >> > After this Form row has been executed the situation should >> look like >> > this: >> > >> > [Book] [Author] >> > The pages objects are left unlinked, the Title and the >> properties >> > First name and Last name are assigned though, and thus the >> page is a >> > "valid" object on it's own, even if the final linking to >> the book >> > would fail or wouldn't happen due to the main form (the >> Book) were >> > canceled. >> > >> > #3. At last, create the link object (page) and assign the >> two 1..n >> > links: >> > >> > {{{createpage|BookAuthorLink >> > | role1={{#var: BookTitle}} >> > | role2={{{First name}}} {{{Last name}}} >> > }}} >> > >> > Now the situation should be this (in UML representation): >> > >> > [Book]<-1-role1--*-[BookAuthorLink]-*--role2-1->[Author] >> > >> > (I would of course name the link properties to Book and Author >> > respectively, because when later #asking if the link what's >> in the >> > other end the semantics of names like "role1" and "role2" >> doesn't >> > say what the role1 end page and role2 end page really is. >> > >> > Moreover, since the page title of the linking page (object) >> needs >> > to be unique it could be autogenerated based on a "ClassName >> > (Subject-Object)" formula, that is, in this example the title of >> > the BookAuthorLink would end up being: >> > >> > "BookAuthorLink (How to define n..n relations-Yaron Koren)" >> > >> > If the creating of pages and assigning of properties is done via >> > templates (which I strongly suggest) then the definitions >> above on >> > the Form:Book could like something like this: >> > >> > Form:Book >> > ------------------------------------------------ >> > >> > /** >> > * Step 1: >> > * >> > * Class Book, "main form" >> > */ >> > >> > {{{for template|Book}}} >> > {| class="formtable" >> > ! Book title: >> > | {{{field|Book title|mandatory}}} >> > |- >> > ! Sub title: >> > | {{{field|Sub title}}} >> > |- >> > ! Edition: >> > | {{{field|Edition}}} >> > |} >> > {{{end template}}} >> > >> > /** >> > * Step 2: >> > * >> > * Class Author, "sub form", auto created (if not >> > * exist, in any case the variable for the final >> > * title is set. >> > * >> > * If we can get back the final title of the new >> > * page as a return value from the createpage func- >> > * tion, it can be used in later stages below. See >> > * below how "{{{info|" returns the new title: >> > */ >> > >> > {{#vardefine: AuthorName >> > | {{{info|*createpage*|page name=/<Author/[/First name]> >> > //<Author/[/Last name/]> (<unique number>)}}} >> > }} >> > {{{for template|Author}}} >> > {| class="formtable" >> > ! First name: >> > | {{{field|First name|mandatory}}} >> > |- >> > ! Last name: >> > | {{{field|Last name}}} >> > |} >> > {{{end template}}} >> > >> > Given that all properties of the involved forms up till this row >> > are parsed and assigned to variables and named parameters, (thus >> > all involved page titles are available to the code below): >> > >> > /** >> > * Step 3: >> > * >> > * Class BookAuthorLink >> > * >> > * Links together the Book (this page) and the newly >> > * created (or the retrieved title of the) Author. >> > * This form need not be visible at all, and so it >> > * could possibly use a template directly (?). >> > */ >> > >> > {{{info|*createpage*|page name=/BookAuthorLink ({{{Book >> title}}}/ >> > /{{#var:AuthorName}}) /}}} >> > {{{for template|BookAuthorLink}}} >> > {{{field|Role1={{{BookTitle}}}|mandatory}}} >> > {{{field|Role2={{{AuthorName}}}|mandatory}}} >> > {{{end template}}} >> > >> > or a direct call to a independent #createpage ParserFunction >> > capable of assigning property values: >> > >> > {{#createpage:BookAuthorLink >> > | Role1={{{BookTitle}}} >> > | Role2={{{AuthorName}}} >> > }} >> > >> > >> > An option for the #createpage call would be whether its >> allowed to >> > modify any properties if the page already exists (default = >> nope). >> > A first approach wouldn't have to bother about determining >> > conflicts at all. It would be good enough if the form were >> capable >> > of actually creating the Author object (or retrieving if it >> > already exists) when the user presses Submit for that particular >> > SUBFORM (as opposed to submitting the main form), and so the >> user >> > would have the chance to know whether he's about to overwrite >> > something he didn't intend to modify. >> > >> > One point with this example is the if one manages to define >> how to >> > automagically create a 1..n relation, then it's not more >> difficult >> > to define a n..n relation either, it only takes defining yet >> > another such 1..n relation. >> > >> > What do you think Yaron? Shall I implement this notation in the >> > SmwModeler generator now already (tonight) or should I wait >> until >> > you confirm how you prefer to implement this? ... :) <ducking> >> > >> > Regards, >> > >> > // Rolf Lampa >> > >> > >> > >> > >> > Yaron Koren wrote: >> > >> > Hi, >> > >> > Thanks for that full explanation. I think you've confirmed >> > what I had previously suspected, which is that any >> solution to >> > creating automatic "linker" pages would be too involved and >> > complex to implement, given that it would be just an interim >> > solution until true n-ary relations are supported; the >> benefit >> > wouldn't outweigh the complexity. But it's good to know that >> > for sure. >> > >> > Dan - your example is relatively simple and straightforward; >> > however, I think it's outside the scope of this discussion, >> > since it covers the case of two page types, and what's being >> > discussed is having three page types, with one being a >> linker >> > between the other two. >> > >> > -Yaron >> > >> > >> > On Sat, Jan 24, 2009 at 10:52 AM, Rolf Lampa [RIL] >> > <rol...@ri... <mailto:rol...@ri...> >> <mailto:rol...@ri... <mailto:rol...@ri...>> >> > <mailto:rol...@ri... >> <mailto:rol...@ri...> <mailto:rol...@ri... >> <mailto:rol...@ri...>>>> >> > wrote: >> > >> > >> > Regarding the typical "constraint approach" of UML (I'm >> > thinking >> > especially about the 1..n relation) I'm sensing an >> emerging >> > clash >> > between open and closed semantic paradigms here... :) >> > >> > Would be interesting with some philosophical reflexions >> > over this >> > possible clash of paradigm from experts on semantic >> theory. >> > >> > // Rolf Lampa >> > >> > >> > >> ------------------------------------------------------------------------------ >> > This SF.net email is sponsored by: >> > SourcForge Community >> > SourceForge wants to tell your story. >> > http://p.sf.net/sfu/sf-spreadtheword >> > _______________________________________________ >> > Semediawiki-devel mailing list >> > Sem...@li... >> <mailto:Sem...@li...> >> > <mailto:Sem...@li... >> <mailto:Sem...@li...>> >> > <mailto:Sem...@li... >> <mailto:Sem...@li...> >> > <mailto:Sem...@li... >> <mailto:Sem...@li...>>> >> > >> > >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> > >> > >> > >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> <mailto:Sem...@li...> >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> >> >> > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > |