From: Jamie T. <ja...@th...> - 2012-07-28 03:45:17
|
Hello, I'm finding myself confused about the native SMW #subobject and the SIO specific objects. I have used both in different wikis and mostly I'm using them in association with multiply occurring forms in Semantic Forms. I'm finding SMW #subobjects a bit frustrating as I typically have to set a variable and iterate to create a unique name for each subobject, and I typically don't care about the names. I would probably be better off using SIO. If you want to see an example of where I'm using #subobject check out my Kubb scoresheet here: http://wiki.planetkubb.com/wiki/US_Nationals_2012,_Finals,_Knockerheads_v._Kubbsicles,_July_15_(Game_1) Properties here: http://wiki.planetkubb.com/wiki/Special:Browse/US_Nationals_2012,_Finals,_Knockerheads_v._Kubbsicles,_July_15_(Game_1) This works, but I'm feeling like I should stop the #subobject and move back to SIO because I'm going to want to do some massive queries across subobjects of hundreds of games, which seems better fit for SIO. My big angst with this come from worrying that SIO is inevitably going to go away and be superseded by SMW #subobject. Is SIO planned to be supported for the foreseeable future? Is the plan to merge it all into SMW directly? I've already got SIO installed, so it's easy enough to use but I'm fearful of a release in the near future that requires me to refactore SIO out and use native SMW #subobject. The SIO wiki page has a writeup of the differences, but there isn't a clear position on continued development. Would love to hear what the plans are. Jamie Thingelstad ja...@th... mobile: 612-810-3699 find me on AIM Twitter Facebook LinkedIn |
From: Markus K. <ma...@se...> - 2012-07-28 17:24:05
|
Hi Jamie, good questions; here are the answers: (1) #subobject is an SMW parser function that is implemented by using SMW's native subobject support. The requirement to name a subobject is created by the implementation of #subobject and is about to vanish (an according change is to be merged into SMW soon [1]). (2) The SIO extension is implemented by accessing the SMW database tables directly. This is hopefully soon going to change so that SIO will also be based on SMW's native subobject support. We only discussed this recently, but doing this change should be very easy (one short PHP file will be enough to get SIO). (3) With this change, both approaches should work indefinitely, and be compatible on a data level (one could create exactly the same data using either function). Moreover, it would be easy to create more such functions that have other kinds of special behaviour. (4) A difference between SIO and #subobject is that both take a property, but in SIO the property links from the subobject to the page, and in #subobject it points from the page to the subobject. This is not a real limitation. You can add a property to any #subobject that points to the page (just like any other property) if you want to link back. Likewise, you could link from the page to an SIO if you know the name of the SIO. It is not a problem to have links in both directions. (5) The subobject feature being built into SMW, there will be continued efforts to make it more efficient and better supported in all UIs. Cheers, Markus [1] https://gerrit.wikimedia.org/r/#/c/16884/ On 28/07/12 04:21, Jamie Thingelstad wrote: > Hello, > > I'm finding myself confused about the native SMW #subobject and the SIO specific objects. I have used both in different wikis and mostly I'm using them in association with multiply occurring forms in Semantic Forms. > > I'm finding SMW #subobjects a bit frustrating as I typically have to set a variable and iterate to create a unique name for each subobject, and I typically don't care about the names. I would probably be better off using SIO. If you want to see an example of where I'm using #subobject check out my Kubb scoresheet here: > > http://wiki.planetkubb.com/wiki/US_Nationals_2012,_Finals,_Knockerheads_v._Kubbsicles,_July_15_(Game_1) > > Properties here: > > http://wiki.planetkubb.com/wiki/Special:Browse/US_Nationals_2012,_Finals,_Knockerheads_v._Kubbsicles,_July_15_(Game_1) > > This works, but I'm feeling like I should stop the #subobject and move back to SIO because I'm going to want to do some massive queries across subobjects of hundreds of games, which seems better fit for SIO. > > My big angst with this come from worrying that SIO is inevitably going to go away and be superseded by SMW #subobject. Is SIO planned to be supported for the foreseeable future? Is the plan to merge it all into SMW directly? I've already got SIO installed, so it's easy enough to use but I'm fearful of a release in the near future that requires me to refactore SIO out and use native SMW #subobject. > > The SIO wiki page has a writeup of the differences, but there isn't a clear position on continued development. > > Would love to hear what the plans are. > Jamie Thingelstad > ja...@th... > mobile: 612-810-3699 > find me on AIM Twitter Facebook LinkedIn > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > |
From: Markus K. <ma...@se...> - 2012-07-28 17:34:09
|
On 28/07/12 18:23, Markus Krötzsch wrote: > Hi Jamie, > > good questions; here are the answers: > > (1) #subobject is an SMW parser function that is implemented by using > SMW's native subobject support. The requirement to name a subobject is > created by the implementation of #subobject and is about to vanish (an > according change is to be merged into SMW soon [1]). > > (2) The SIO extension is implemented by accessing the SMW database > tables directly. This is hopefully soon going to change so that SIO will > also be based on SMW's native subobject support. We only discussed this > recently, but doing this change should be very easy (one short PHP file > will be enough to get SIO). > > (3) With this change, both approaches should work indefinitely, and be > compatible on a data level (one could create exactly the same data using > either function). Moreover, it would be easy to create more such > functions that have other kinds of special behaviour. > > (4) A difference between SIO and #subobject is that both take a > property, but in SIO the property links from the subobject to the page, > and in #subobject it points from the page to the subobject. This is not > a real limitation. You can add a property to any #subobject that points > to the page (just like any other property) if you want to link back. > Likewise, you could link from the page to an SIO if you know the name of > the SIO. It is not a problem to have links in both directions. > > (5) The subobject feature being built into SMW, there will be continued > efforts to make it more efficient and better supported in all UIs. One more thing: (6) Any parser function that allows you to name subobjects explicitly will normally work in an additive fashion if you use the same name multiple times. For example, having multiple #subobject blocks with the same subobject name will create one subobject with all of the given features combined. If you use anonymous subobjects, subobjects will be created for every #subobject call (unless there is already an object with exactly the same assignment of values on the same page). Cheers, Markus > > [1] https://gerrit.wikimedia.org/r/#/c/16884/ > > > > On 28/07/12 04:21, Jamie Thingelstad wrote: >> Hello, >> >> I'm finding myself confused about the native SMW #subobject and the >> SIO specific objects. I have used both in different wikis and mostly >> I'm using them in association with multiply occurring forms in >> Semantic Forms. >> >> I'm finding SMW #subobjects a bit frustrating as I typically have to >> set a variable and iterate to create a unique name for each subobject, >> and I typically don't care about the names. I would probably be better >> off using SIO. If you want to see an example of where I'm using >> #subobject check out my Kubb scoresheet here: >> >> http://wiki.planetkubb.com/wiki/US_Nationals_2012,_Finals,_Knockerheads_v._Kubbsicles,_July_15_(Game_1) >> >> >> Properties here: >> >> http://wiki.planetkubb.com/wiki/Special:Browse/US_Nationals_2012,_Finals,_Knockerheads_v._Kubbsicles,_July_15_(Game_1) >> >> >> This works, but I'm feeling like I should stop the #subobject and move >> back to SIO because I'm going to want to do some massive queries >> across subobjects of hundreds of games, which seems better fit for SIO. >> >> My big angst with this come from worrying that SIO is inevitably going >> to go away and be superseded by SMW #subobject. Is SIO planned to be >> supported for the foreseeable future? Is the plan to merge it all into >> SMW directly? I've already got SIO installed, so it's easy enough to >> use but I'm fearful of a release in the near future that requires me >> to refactore SIO out and use native SMW #subobject. >> >> The SIO wiki page has a writeup of the differences, but there isn't a >> clear position on continued development. >> >> Would love to hear what the plans are. >> Jamie Thingelstad >> ja...@th... >> mobile: 612-810-3699 >> find me on AIM Twitter Facebook LinkedIn >> >> ------------------------------------------------------------------------------ >> >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Semediawiki-user mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >> > > |
From: Yaron K. <ya...@wi...> - 2012-07-29 03:31:47
|
Hi Jamie, The short answer is that I plan to keep supporting Semantic Internal Objects until there's no longer a reason to do it. At the moment, SIO does indeed have some advantages over #subobject. In the long term, though, I'd have to imagine that SMW will contain the definitive way to store two-dimensional data on a page, and thus that SIO will no longer be needed - it's just too important a feature for SMW not to support it directly (and fully), I would think. By a remarkable coincidence (or maybe it wasn't a coincidence), just an hour or so after you sent that email, Mwjames submitted a patch to Semantic MediaWiki that, if I understand it correctly, removes what you correctly note is subobjects' current greatest weakness - their lack of automatically-assigned names: https://gerrit.wikimedia.org/r/#/c/16884/ It's just a short amount of code, but it could really change everything as far as the usefulness of #subobject. Of course, it needs review and so on, but if it gets added in, this could be a big step on the way to removing the need for SIO. Not the last step, though - there's still the matter of creating counterparts for #set_internal_recurring_event and External Data's #store_external_table. So yes, I imagine that at some point I'll stop maintaining SIO, and then everyone using it in their wikis will be encouraged to change their #set_internal calls to #subobject (or whatever it will be called at the time). And it probably won't be just a matter of replacing one function name with another, unfortunately, since the two have somewhat different syntax. But hopefully it won't be that painful. And whether that happens in a month or three years, I can't say. -Yaron On Fri, Jul 27, 2012 at 11:21 PM, Jamie Thingelstad <ja...@th...>wrote: > Hello, > > I'm finding myself confused about the native SMW #subobject and the SIO > specific objects. I have used both in different wikis and mostly I'm using > them in association with multiply occurring forms in Semantic Forms. > > I'm finding SMW #subobjects a bit frustrating as I typically have to set a > variable and iterate to create a unique name for each subobject, and I > typically don't care about the names. I would probably be better off using > SIO. If you want to see an example of where I'm using #subobject check out > my Kubb scoresheet here: > > > http://wiki.planetkubb.com/wiki/US_Nationals_2012,_Finals,_Knockerheads_v._Kubbsicles,_July_15_(Game_1) > > Properties here: > > > http://wiki.planetkubb.com/wiki/Special:Browse/US_Nationals_2012,_Finals,_Knockerheads_v._Kubbsicles,_July_15_(Game_1) > > This works, but I'm feeling like I should stop the #subobject and move > back to SIO because I'm going to want to do some massive queries across > subobjects of hundreds of games, which seems better fit for SIO. > > My big angst with this come from worrying that SIO is inevitably going to > go away and be superseded by SMW #subobject. Is SIO planned to be supported > for the foreseeable future? Is the plan to merge it all into SMW directly? > I've already got SIO installed, so it's easy enough to use but I'm fearful > of a release in the near future that requires me to refactore SIO out and > use native SMW #subobject. > > The SIO wiki page has a writeup of the differences, but there isn't a > clear position on continued development. > > Would love to hear what the plans are. > Jamie Thingelstad > ja...@th... > mobile: 612-810-3699 > find me on AIM Twitter Facebook LinkedIn > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Yury K. <kat...@gm...> - 2012-07-29 08:56:27
|
I suppose that when the subobject feature is as mature as semantic internal objects now, it will be easy to write a converter bot to help users with the transition. ----- Yury Katkov On Sun, Jul 29, 2012 at 7:31 AM, Yaron Koren <ya...@wi...> wrote: > Hi Jamie, > > The short answer is that I plan to keep supporting Semantic Internal > Objects until there's no longer a reason to do it. At the moment, SIO does > indeed have some advantages over #subobject. In the long term, though, I'd > have to imagine that SMW will contain the definitive way to store > two-dimensional data on a page, and thus that SIO will no longer be needed > - it's just too important a feature for SMW not to support it directly (and > fully), I would think. > > By a remarkable coincidence (or maybe it wasn't a coincidence), just an > hour or so after you sent that email, Mwjames submitted a patch to Semantic > MediaWiki that, if I understand it correctly, removes what you correctly > note is subobjects' current greatest weakness - their lack of > automatically-assigned names: > > https://gerrit.wikimedia.org/r/#/c/16884/ > > It's just a short amount of code, but it could really change everything as > far as the usefulness of #subobject. Of course, it needs review and so on, > but if it gets added in, this could be a big step on the way to removing > the need for SIO. Not the last step, though - there's still the matter of > creating counterparts for #set_internal_recurring_event and External Data's > #store_external_table. > > So yes, I imagine that at some point I'll stop maintaining SIO, and then > everyone using it in their wikis will be encouraged to change their > #set_internal calls to #subobject (or whatever it will be called at the > time). And it probably won't be just a matter of replacing one function > name with another, unfortunately, since the two have somewhat different > syntax. But hopefully it won't be that painful. And whether that happens in > a month or three years, I can't say. > > -Yaron > > > On Fri, Jul 27, 2012 at 11:21 PM, Jamie Thingelstad > <ja...@th...>wrote: > > > Hello, > > > > I'm finding myself confused about the native SMW #subobject and the SIO > > specific objects. I have used both in different wikis and mostly I'm > using > > them in association with multiply occurring forms in Semantic Forms. > > > > I'm finding SMW #subobjects a bit frustrating as I typically have to set > a > > variable and iterate to create a unique name for each subobject, and I > > typically don't care about the names. I would probably be better off > using > > SIO. If you want to see an example of where I'm using #subobject check > out > > my Kubb scoresheet here: > > > > > > > http://wiki.planetkubb.com/wiki/US_Nationals_2012,_Finals,_Knockerheads_v._Kubbsicles,_July_15_(Game_1) > > > > Properties here: > > > > > > > http://wiki.planetkubb.com/wiki/Special:Browse/US_Nationals_2012,_Finals,_Knockerheads_v._Kubbsicles,_July_15_(Game_1) > > > > This works, but I'm feeling like I should stop the #subobject and move > > back to SIO because I'm going to want to do some massive queries across > > subobjects of hundreds of games, which seems better fit for SIO. > > > > My big angst with this come from worrying that SIO is inevitably going to > > go away and be superseded by SMW #subobject. Is SIO planned to be > supported > > for the foreseeable future? Is the plan to merge it all into SMW > directly? > > I've already got SIO installed, so it's easy enough to use but I'm > fearful > > of a release in the near future that requires me to refactore SIO out and > > use native SMW #subobject. > > > > The SIO wiki page has a writeup of the differences, but there isn't a > > clear position on continued development. > > > > Would love to hear what the plans are. > > Jamie Thingelstad > > ja...@th... > > mobile: 612-810-3699 > > find me on AIM Twitter Facebook LinkedIn > > > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Semediawiki-user mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > |
From: Cavila C. <con...@ho...> - 2012-07-30 09:07:23
|
Dear all, I was previously under the impression that I had a workable workaround for this issue, namely using the Variables extension as once suggested by someone on this list, but MW James has kindly pointed out some potential problems with this approach. I was working on a table of comparison for SIOs vs subobjects, but couldn't find the time to finish it. Possibly one of the great strengths of subobjects over SIOs is currently their ease of use in combination with 'regular' #ask queries. Its greatest weakness I would say is not the autonumbering issue, but a limitation in defining property values. If I'm not mistaken (I may very well be though!), you can only specify one value per property. Multiple values are possible with SIO, but the problem there is that commas, and commas only, are used as delimiters. If one day Semantic Forms could handle multiple pages along the lines of Semantic Multi Edit Extension (in addition to handling multiple instances of a template) and transclusion can be done more flexibly, I'd probably have less need of subobjects / SIOs. C. > From: kat...@gm... > Date: Sun, 29 Jul 2012 12:55:50 +0400 > To: ya...@wi... > CC: sem...@li... > Subject: Re: [Semediawiki-user] Future plans for Semantic MediaWiki #suboject and Semantic Internal Objects > > I suppose that when the subobject feature is as mature as semantic internal > objects now, it will be easy to write a converter bot to help users with > the transition. > ----- > Yury Katkov > > > > > On Sun, Jul 29, 2012 at 7:31 AM, Yaron Koren <ya...@wi...> wrote: > > > Hi Jamie, > > > > The short answer is that I plan to keep supporting Semantic Internal > > Objects until there's no longer a reason to do it. At the moment, SIO does > > indeed have some advantages over #subobject. In the long term, though, I'd > > have to imagine that SMW will contain the definitive way to store > > two-dimensional data on a page, and thus that SIO will no longer be needed > > - it's just too important a feature for SMW not to support it directly (and > > fully), I would think. > > > > By a remarkable coincidence (or maybe it wasn't a coincidence), just an > > hour or so after you sent that email, Mwjames submitted a patch to Semantic > > MediaWiki that, if I understand it correctly, removes what you correctly > > note is subobjects' current greatest weakness - their lack of > > automatically-assigned names: > > > > https://gerrit.wikimedia.org/r/#/c/16884/ > > > > It's just a short amount of code, but it could really change everything as > > far as the usefulness of #subobject. Of course, it needs review and so on, > > but if it gets added in, this could be a big step on the way to removing > > the need for SIO. Not the last step, though - there's still the matter of > > creating counterparts for #set_internal_recurring_event and External Data's > > #store_external_table. > > > > So yes, I imagine that at some point I'll stop maintaining SIO, and then > > everyone using it in their wikis will be encouraged to change their > > #set_internal calls to #subobject (or whatever it will be called at the > > time). And it probably won't be just a matter of replacing one function > > name with another, unfortunately, since the two have somewhat different > > syntax. But hopefully it won't be that painful. And whether that happens in > > a month or three years, I can't say. > > > > -Yaron > > > > > > On Fri, Jul 27, 2012 at 11:21 PM, Jamie Thingelstad > > <ja...@th...>wrote: > > > > > Hello, > > > > > > I'm finding myself confused about the native SMW #subobject and the SIO > > > specific objects. I have used both in different wikis and mostly I'm > > using > > > them in association with multiply occurring forms in Semantic Forms. > > > > > > I'm finding SMW #subobjects a bit frustrating as I typically have to set > > a > > > variable and iterate to create a unique name for each subobject, and I > > > typically don't care about the names. I would probably be better off > > using > > > SIO. If you want to see an example of where I'm using #subobject check > > out > > > my Kubb scoresheet here: > > > > > > > > > > > http://wiki.planetkubb.com/wiki/US_Nationals_2012,_Finals,_Knockerheads_v._Kubbsicles,_July_15_(Game_1) > > > > > > Properties here: > > > > > > > > > > > http://wiki.planetkubb.com/wiki/Special:Browse/US_Nationals_2012,_Finals,_Knockerheads_v._Kubbsicles,_July_15_(Game_1) > > > > > > This works, but I'm feeling like I should stop the #subobject and move > > > back to SIO because I'm going to want to do some massive queries across > > > subobjects of hundreds of games, which seems better fit for SIO. > > > > > > My big angst with this come from worrying that SIO is inevitably going to > > > go away and be superseded by SMW #subobject. Is SIO planned to be > > supported > > > for the foreseeable future? Is the plan to merge it all into SMW > > directly? > > > I've already got SIO installed, so it's easy enough to use but I'm > > fearful > > > of a release in the near future that requires me to refactore SIO out and > > > use native SMW #subobject. > > > > > > The SIO wiki page has a writeup of the differences, but there isn't a > > > clear position on continued development. > > > > > > Would love to hear what the plans are. > > > Jamie Thingelstad > > > ja...@th... > > > mobile: 612-810-3699 > > > find me on AIM Twitter Facebook LinkedIn > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Live Security Virtual Conference > > > Exclusive live event will cover all the ways today's security and > > > threat landscape has changed and how IT managers can respond. Discussions > > > will include endpoint security, mobile security and the latest in malware > > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > _______________________________________________ > > > Semediawiki-user mailing list > > > Sem...@li... > > > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > > > > > > > > > > -- > > WikiWorks · MediaWiki Consulting · http://wikiworks.com > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Semediawiki-user mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user |
From: Yaron K. <ya...@wi...> - 2012-07-30 13:15:00
|
Hi Cavila, > Possibly one of the great strengths of subobjects over SIOs is currently > their ease of use in combination with 'regular' #ask queries. > What do you mean by this? The two are queried in essentially the same way. -Yaron |
From: Markus K. <ma...@se...> - 2012-07-30 12:49:57
|
Update and further clarifications: (7) The patch of mwjames has already been merged. The next SWM version will support #subobject without a name given. You can get this feature immediately by using the file SMW_Subobject.php from the development version of SMW (it has no dependencies on other changes) [1]. (8) #subobject supports multiple values per property, but not with a deliminter (like ","). I have changed this now to support "|" as a delimiter. This does not create new restrictions on values (| is already used as a delimiter anyway) but provides a convenient shortcut. Another way to add multiple values for one property is to repeat the name of the property. So the following two notations lead to the same data: {{#subobject:mysubobject |property1=value1 |property1=value2 }} {#subobject:mysubobject |property1=value1|value2 }} This is already implemented in the file at [1]. (9) Even if Yaron considers to phase out SIO at some point, it would still be easy to maintain a basic version that continues to support the old syntax, in case a wiki finds it too hard to convert. The implementation would not have dependencies on SMW internals (like DB layout), so it should be low effort to maintain this. The file at [1] shows how little code is needed for such a function. Cheers, Markus [1] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/SemanticMediaWiki.git;a=blob;f=includes/parserhooks/SMW_Subobject.php On 30/07/12 10:07, Cavila Contrafibularity wrote: > > Dear all, > > I was previously under the impression that I had a workable workaround for this issue, namely using the Variables extension as once suggested by someone on this list, but MW James has kindly pointed out some potential problems with this approach. > > I was working on a table of comparison for SIOs vs subobjects, but couldn't find the time to finish it. Possibly one of the great strengths of subobjects over SIOs is currently their ease of use in combination with 'regular' #ask queries. Its greatest weakness I would say is not the autonumbering issue, but a limitation in defining property values. If I'm not mistaken (I may very well be though!), you can only specify one value per property. Multiple values are possible with SIO, but the problem there is that commas, and commas only, are used as delimiters. > > If one day Semantic Forms could handle multiple pages along the lines of Semantic Multi Edit Extension (in addition to handling multiple instances of a template) and transclusion can be done more flexibly, I'd probably have less need of subobjects / SIOs. > > C. > >> From: kat...@gm... >> Date: Sun, 29 Jul 2012 12:55:50 +0400 >> To: ya...@wi... >> CC: sem...@li... >> Subject: Re: [Semediawiki-user] Future plans for Semantic MediaWiki #suboject and Semantic Internal Objects >> >> I suppose that when the subobject feature is as mature as semantic internal >> objects now, it will be easy to write a converter bot to help users with >> the transition. >> ----- >> Yury Katkov >> >> >> >> >> On Sun, Jul 29, 2012 at 7:31 AM, Yaron Koren <ya...@wi...> wrote: >> >>> Hi Jamie, >>> >>> The short answer is that I plan to keep supporting Semantic Internal >>> Objects until there's no longer a reason to do it. At the moment, SIO does >>> indeed have some advantages over #subobject. In the long term, though, I'd >>> have to imagine that SMW will contain the definitive way to store >>> two-dimensional data on a page, and thus that SIO will no longer be needed >>> - it's just too important a feature for SMW not to support it directly (and >>> fully), I would think. >>> >>> By a remarkable coincidence (or maybe it wasn't a coincidence), just an >>> hour or so after you sent that email, Mwjames submitted a patch to Semantic >>> MediaWiki that, if I understand it correctly, removes what you correctly >>> note is subobjects' current greatest weakness - their lack of >>> automatically-assigned names: >>> >>> https://gerrit.wikimedia.org/r/#/c/16884/ >>> >>> It's just a short amount of code, but it could really change everything as >>> far as the usefulness of #subobject. Of course, it needs review and so on, >>> but if it gets added in, this could be a big step on the way to removing >>> the need for SIO. Not the last step, though - there's still the matter of >>> creating counterparts for #set_internal_recurring_event and External Data's >>> #store_external_table. >>> >>> So yes, I imagine that at some point I'll stop maintaining SIO, and then >>> everyone using it in their wikis will be encouraged to change their >>> #set_internal calls to #subobject (or whatever it will be called at the >>> time). And it probably won't be just a matter of replacing one function >>> name with another, unfortunately, since the two have somewhat different >>> syntax. But hopefully it won't be that painful. And whether that happens in >>> a month or three years, I can't say. >>> >>> -Yaron >>> >>> >>> On Fri, Jul 27, 2012 at 11:21 PM, Jamie Thingelstad >>> <ja...@th...>wrote: >>> >>>> Hello, >>>> >>>> I'm finding myself confused about the native SMW #subobject and the SIO >>>> specific objects. I have used both in different wikis and mostly I'm >>> using >>>> them in association with multiply occurring forms in Semantic Forms. >>>> >>>> I'm finding SMW #subobjects a bit frustrating as I typically have to set >>> a >>>> variable and iterate to create a unique name for each subobject, and I >>>> typically don't care about the names. I would probably be better off >>> using >>>> SIO. If you want to see an example of where I'm using #subobject check >>> out >>>> my Kubb scoresheet here: >>>> >>>> >>>> >>> http://wiki.planetkubb.com/wiki/US_Nationals_2012,_Finals,_Knockerheads_v._Kubbsicles,_July_15_(Game_1) >>>> >>>> Properties here: >>>> >>>> >>>> >>> http://wiki.planetkubb.com/wiki/Special:Browse/US_Nationals_2012,_Finals,_Knockerheads_v._Kubbsicles,_July_15_(Game_1) >>>> >>>> This works, but I'm feeling like I should stop the #subobject and move >>>> back to SIO because I'm going to want to do some massive queries across >>>> subobjects of hundreds of games, which seems better fit for SIO. >>>> >>>> My big angst with this come from worrying that SIO is inevitably going to >>>> go away and be superseded by SMW #subobject. Is SIO planned to be >>> supported >>>> for the foreseeable future? Is the plan to merge it all into SMW >>> directly? >>>> I've already got SIO installed, so it's easy enough to use but I'm >>> fearful >>>> of a release in the near future that requires me to refactore SIO out and >>>> use native SMW #subobject. >>>> >>>> The SIO wiki page has a writeup of the differences, but there isn't a >>>> clear position on continued development. >>>> >>>> Would love to hear what the plans are. >>>> Jamie Thingelstad >>>> ja...@th... >>>> mobile: 612-810-3699 >>>> find me on AIM Twitter Facebook LinkedIn >>>> >>>> >>>> >>> ------------------------------------------------------------------------------ >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. Discussions >>>> will include endpoint security, mobile security and the latest in malware >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> _______________________________________________ >>>> Semediawiki-user mailing list >>>> Sem...@li... >>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >>>> >>> >>> >>> >>> -- >>> WikiWorks · MediaWiki Consulting · http://wikiworks.com >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Semediawiki-user mailing list >>> Sem...@li... >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >>> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Semediawiki-user mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > |
From: Yaron K. <ya...@wi...> - 2012-07-30 13:35:54
|
Hi Markus, > (8) #subobject supports multiple values per property, but not with a > deliminter (like ","). I have changed this now to support "|" as a > delimiter. This does not create new restrictions on values (| is already > used as a delimiter anyway) but provides a convenient shortcut. Another way > to add multiple values for one property is to repeat the name of the > property. So the following two notations lead to the same data: > > {{#subobject:mysubobject > |property1=value1 > |property1=value2 > }} > > {#subobject:mysubobject > |property1=value1|value2 > }} > The fact that there's support now for multiple values is good, but do you know if the pipe notation can be reproduced using #arraymap? Ideally, something like this would work: {{#subobject:#|property1={{#arraymap:{{{values1|}}}|,|x|x|{{!}} }} My guess is that it wouldn't work, but I could be wrong. If it doesn't work, I'd say it's worth changing the notation, or adding an additional notation, because #arraymap is the way almost everyone would be setting multiple values. -Yaron |
From: Markus K. <ma...@se...> - 2012-07-30 13:58:28
|
On 30/07/12 14:35, Yaron Koren wrote: > Hi Markus, > > (8) #subobject supports multiple values per property, but not with a > deliminter (like ","). I have changed this now to support "|" as a > delimiter. This does not create new restrictions on values (| is > already used as a delimiter anyway) but provides a convenient > shortcut. Another way to add multiple values for one property is to > repeat the name of the property. So the following two notations lead > to the same data: > > {{#subobject:mysubobject > |property1=value1 > |property1=value2 > }} > > {#subobject:mysubobject > |property1=value1|value2 > }} > > > The fact that there's support now for multiple values is good, but do > you know if the pipe notation can be reproduced using #arraymap? > Ideally, something like this would work: > > {{#subobject:#|property1={{#arraymap:{{{values1|}}}|,|x|x|{{!}} }} > > My guess is that it wouldn't work, but I could be wrong. If it doesn't > work, I'd say it's worth changing the notation, or adding an additional > notation, because #arraymap is the way almost everyone would be setting > multiple values. The above is unlikely to work. Even {{!}} should not work. In fact, {{!}} is the standard way to encode a | if one wants it to not affect parsing. If we further augment the notation, we would disallow more characters in property values, which we'd really want to avoid. I do not know a good solution for this. Ideally, something like #arraymap would solve the problem in a modular way, but we would still need at least one base syntax for a non-MW separator symbol that would then become unavailable in property values. One could make this configurable to avoid the problem, but then one needs additional syntax that is likely to make everything more complicated. Any syntax proposals? It would be easier to add multiple values to a subobject that has a name. The problem here is that due to the use of anonymous subobjects, one needs to add all the data within one parser function call, and MW just does not support dynamic numbers of parser function parameters based on nested template or parser function code. Markus |
From: Yaron K. <ya...@wi...> - 2012-07-30 14:56:06
|
Hi Markus, Yes, as far as I know, there's no ideal solution - the constraints imposed by MediaWiki's syntax unfortunately make it difficult or impossible to do this kind of thing without creating new "forbidden" characters. The solution used by #set_internal, of having "property1#list=value1", seems to work fine most of the time, even though it makes commas unusable in property values. (I should note that the "#list" notation was first proposed - though not actually implemented - for the SMW #declare function, for what it's worth.) What about having that as alternate syntax, so that there would be three ways of setting a list of values for a property? By the way, the #list notation wouldn't have to use commas - another obvious delimiter character to use is semicolons, which would probably be an even safer choice. -Yaron On Mon, Jul 30, 2012 at 9:58 AM, Markus Krötzsch < ma...@se...> wrote: > On 30/07/12 14:35, Yaron Koren wrote: > >> Hi Markus, >> >> (8) #subobject supports multiple values per property, but not with a >> deliminter (like ","). I have changed this now to support "|" as a >> delimiter. This does not create new restrictions on values (| is >> already used as a delimiter anyway) but provides a convenient >> shortcut. Another way to add multiple values for one property is to >> repeat the name of the property. So the following two notations lead >> to the same data: >> >> {{#subobject:mysubobject >> |property1=value1 >> |property1=value2 >> }} >> >> {#subobject:mysubobject >> |property1=value1|value2 >> }} >> >> >> The fact that there's support now for multiple values is good, but do >> you know if the pipe notation can be reproduced using #arraymap? >> Ideally, something like this would work: >> >> {{#subobject:#|property1={{#**arraymap:{{{values1|}}}|,|x|x|**{{!}} }} >> >> My guess is that it wouldn't work, but I could be wrong. If it doesn't >> work, I'd say it's worth changing the notation, or adding an additional >> notation, because #arraymap is the way almost everyone would be setting >> multiple values. >> > > The above is unlikely to work. Even {{!}} should not work. In fact, {{!}} > is the standard way to encode a | if one wants it to not affect parsing. > > If we further augment the notation, we would disallow more characters in > property values, which we'd really want to avoid. I do not know a good > solution for this. Ideally, something like #arraymap would solve the > problem in a modular way, but we would still need at least one base syntax > for a non-MW separator symbol that would then become unavailable in > property values. One could make this configurable to avoid the problem, but > then one needs additional syntax that is likely to make everything more > complicated. Any syntax proposals? > > It would be easier to add multiple values to a subobject that has a name. > The problem here is that due to the use of anonymous subobjects, one needs > to add all the data within one parser function call, and MW just does not > support dynamic numbers of parser function parameters based on nested > template or parser function code. > > Markus > > > > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Cavila C. <con...@ho...> - 2012-07-31 12:05:28
|
Thanks all for the helpful feedback, which is much appreciated. So all in all, multiple values are perfectly possible, but embedding the required syntax in a template is something that would require some modifications to the software. There's the present rub, right? Yaron's suggestion seems to me an attractive solution. Semi-colons would work for me. (The only syntax conflict that I can think of is that using HTML to escape characters like square brackets would not be possible.) C. Date: Mon, 30 Jul 2012 10:55:56 -0400 Subject: Re: [Semediawiki-user] Future plans for Semantic MediaWiki #suboject and Semantic Internal Objects From: ya...@wi... To: ma...@se... CC: con...@ho...; kat...@gm...; sem...@li... Hi Markus, Yes, as far as I know, there's no ideal solution - the constraints imposed by MediaWiki's syntax unfortunately make it difficult or impossible to do this kind of thing without creating new "forbidden" characters. The solution used by #set_internal, of having "property1#list=value1", seems to work fine most of the time, even though it makes commas unusable in property values. (I should note that the "#list" notation was first proposed - though not actually implemented - for the SMW #declare function, for what it's worth.) What about having that as alternate syntax, so that there would be three ways of setting a list of values for a property? By the way, the #list notation wouldn't have to use commas - another obvious delimiter character to use is semicolons, which would probably be an even safer choice. -Yaron On Mon, Jul 30, 2012 at 9:58 AM, Markus Krötzsch <ma...@se...> wrote: On 30/07/12 14:35, Yaron Koren wrote: Hi Markus, (8) #subobject supports multiple values per property, but not with a deliminter (like ","). I have changed this now to support "|" as a delimiter. This does not create new restrictions on values (| is already used as a delimiter anyway) but provides a convenient shortcut. Another way to add multiple values for one property is to repeat the name of the property. So the following two notations lead to the same data: {{#subobject:mysubobject |property1=value1 |property1=value2 }} {#subobject:mysubobject |property1=value1|value2 }} The fact that there's support now for multiple values is good, but do you know if the pipe notation can be reproduced using #arraymap? Ideally, something like this would work: {{#subobject:#|property1={{#arraymap:{{{values1|}}}|,|x|x|{{!}} }} My guess is that it wouldn't work, but I could be wrong. If it doesn't work, I'd say it's worth changing the notation, or adding an additional notation, because #arraymap is the way almost everyone would be setting multiple values. The above is unlikely to work. Even {{!}} should not work. In fact, {{!}} is the standard way to encode a | if one wants it to not affect parsing. If we further augment the notation, we would disallow more characters in property values, which we'd really want to avoid. I do not know a good solution for this. Ideally, something like #arraymap would solve the problem in a modular way, but we would still need at least one base syntax for a non-MW separator symbol that would then become unavailable in property values. One could make this configurable to avoid the problem, but then one needs additional syntax that is likely to make everything more complicated. Any syntax proposals? It would be easier to add multiple values to a subobject that has a name. The problem here is that due to the use of anonymous subobjects, one needs to add all the data within one parser function call, and MW just does not support dynamic numbers of parser function parameters based on nested template or parser function code. Markus -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Markus K. <ma...@se...> - 2012-08-02 17:13:47
|
On 31/07/12 13:05, Cavila Contrafibularity wrote: > Thanks all for the helpful feedback, which is much appreciated. > > So all in all, multiple values are perfectly possible, but embedding the > required syntax in a template is something that would require some > modifications to the software. There's the present rub, right? > > Yaron's suggestion seems to me an attractive solution. Semi-colons would > work for me. (The only syntax conflict that I can think of is that using > HTML to escape characters like square brackets would not be possible.) As I said, I would not want to block any additional characters, since it is otherwise not possible to create subobject values in such cases at all (#subobject is the main function for doing this, so it should be as unconstrained as possible). However, we could have some syntax for enabling ;-based lists, or we could have another parser function that does just this. It would be good to have a feature request filed for this to make sure it's not forgotten. Markus > > Date: Mon, 30 Jul 2012 10:55:56 -0400 > Subject: Re: [Semediawiki-user] Future plans for Semantic MediaWiki > #suboject and Semantic Internal Objects > From: ya...@wi... > To: ma...@se... > CC: con...@ho...; kat...@gm...; > sem...@li... > > Hi Markus, > > Yes, as far as I know, there's no ideal solution - the constraints > imposed by MediaWiki's syntax unfortunately make it difficult or > impossible to do this kind of thing without creating new "forbidden" > characters. > > The solution used by #set_internal, of having "property1#list=value1", > seems to work fine most of the time, even though it makes commas > unusable in property values. (I should note that the "#list" notation > was first proposed - though not actually implemented - for the SMW > #declare function, for what it's worth.) What about having that as > alternate syntax, so that there would be three ways of setting a list of > values for a property? > > By the way, the #list notation wouldn't have to use commas - another > obvious delimiter character to use is semicolons, which would probably > be an even safer choice. > > -Yaron > > On Mon, Jul 30, 2012 at 9:58 AM, Markus Krötzsch > <ma...@se... <mailto:ma...@se...>> > wrote: > > On 30/07/12 14:35, Yaron Koren wrote: > > Hi Markus, > > (8) #subobject supports multiple values per property, but > not with a > deliminter (like ","). I have changed this now to support > "|" as a > delimiter. This does not create new restrictions on values > (| is > already used as a delimiter anyway) but provides a convenient > shortcut. Another way to add multiple values for one > property is to > repeat the name of the property. So the following two > notations lead > to the same data: > > {{#subobject:mysubobject > |property1=value1 > |property1=value2 > }} > > {#subobject:mysubobject > |property1=value1|value2 > }} > > > The fact that there's support now for multiple values is good, > but do > you know if the pipe notation can be reproduced using #arraymap? > Ideally, something like this would work: > > {{#subobject:#|property1={{# arraymap:{{{values1|}}}|,|x|x| {{!}} }} > > My guess is that it wouldn't work, but I could be wrong. If it > doesn't > work, I'd say it's worth changing the notation, or adding an > additional > notation, because #arraymap is the way almost everyone would be > setting > multiple values. > > > The above is unlikely to work. Even {{!}} should not work. In fact, > {{!}} is the standard way to encode a | if one wants it to not > affect parsing. > > If we further augment the notation, we would disallow more > characters in property values, which we'd really want to avoid. I do > not know a good solution for this. Ideally, something like #arraymap > would solve the problem in a modular way, but we would still need at > least one base syntax for a non-MW separator symbol that would then > become unavailable in property values. One could make this > configurable to avoid the problem, but then one needs additional > syntax that is likely to make everything more complicated. Any > syntax proposals? > > It would be easier to add multiple values to a subobject that has a > name. The problem here is that due to the use of anonymous > subobjects, one needs to add all the data within one parser function > call, and MW just does not support dynamic numbers of parser > function parameters based on nested template or parser function code. > > Markus > > > > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Cavila C. <con...@ho...> - 2012-08-03 20:08:15
|
Filed as bug 39019, with reference to this discussion https://bugzilla.wikimedia.org/show_bug.cgi?id=39019 Hope that helps, C. > Date: Thu, 2 Aug 2012 18:13:38 +0100 > From: ma...@se... > To: con...@ho... > CC: ya...@wi...; kat...@gm...; sem...@li... > Subject: Re: [Semediawiki-user] Future plans for Semantic MediaWiki #suboject and Semantic Internal Objects > > On 31/07/12 13:05, Cavila Contrafibularity wrote: > > Thanks all for the helpful feedback, which is much appreciated. > > > > So all in all, multiple values are perfectly possible, but embedding the > > required syntax in a template is something that would require some > > modifications to the software. There's the present rub, right? > > > > Yaron's suggestion seems to me an attractive solution. Semi-colons would > > work for me. (The only syntax conflict that I can think of is that using > > HTML to escape characters like square brackets would not be possible.) > > As I said, I would not want to block any additional characters, since it > is otherwise not possible to create subobject values in such cases at > all (#subobject is the main function for doing this, so it should be as > unconstrained as possible). However, we could have some syntax for > enabling ;-based lists, or we could have another parser function that > does just this. It would be good to have a feature request filed for > this to make sure it's not forgotten. > > Markus > > > > > Date: Mon, 30 Jul 2012 10:55:56 -0400 > > Subject: Re: [Semediawiki-user] Future plans for Semantic MediaWiki > > #suboject and Semantic Internal Objects > > From: ya...@wi... > > To: ma...@se... > > CC: con...@ho...; kat...@gm...; > > sem...@li... > > > > Hi Markus, > > > > Yes, as far as I know, there's no ideal solution - the constraints > > imposed by MediaWiki's syntax unfortunately make it difficult or > > impossible to do this kind of thing without creating new "forbidden" > > characters. > > > > The solution used by #set_internal, of having "property1#list=value1", > > seems to work fine most of the time, even though it makes commas > > unusable in property values. (I should note that the "#list" notation > > was first proposed - though not actually implemented - for the SMW > > #declare function, for what it's worth.) What about having that as > > alternate syntax, so that there would be three ways of setting a list of > > values for a property? > > > > By the way, the #list notation wouldn't have to use commas - another > > obvious delimiter character to use is semicolons, which would probably > > be an even safer choice. > > > > -Yaron > > > > On Mon, Jul 30, 2012 at 9:58 AM, Markus Krötzsch > > <ma...@se... <mailto:ma...@se...>> > > wrote: > > > > On 30/07/12 14:35, Yaron Koren wrote: > > > > Hi Markus, > > > > (8) #subobject supports multiple values per property, but > > not with a > > deliminter (like ","). I have changed this now to support > > "|" as a > > delimiter. This does not create new restrictions on values > > (| is > > already used as a delimiter anyway) but provides a convenient > > shortcut. Another way to add multiple values for one > > property is to > > repeat the name of the property. So the following two > > notations lead > > to the same data: > > > > {{#subobject:mysubobject > > |property1=value1 > > |property1=value2 > > }} > > > > {#subobject:mysubobject > > |property1=value1|value2 > > }} > > > > > > The fact that there's support now for multiple values is good, > > but do > > you know if the pipe notation can be reproduced using #arraymap? > > Ideally, something like this would work: > > > > {{#subobject:#|property1={{# arraymap:{{{values1|}}}|,|x|x| {{!}} }} > > > > My guess is that it wouldn't work, but I could be wrong. If it > > doesn't > > work, I'd say it's worth changing the notation, or adding an > > additional > > notation, because #arraymap is the way almost everyone would be > > setting > > multiple values. > > > > > > The above is unlikely to work. Even {{!}} should not work. In fact, > > {{!}} is the standard way to encode a | if one wants it to not > > affect parsing. > > > > If we further augment the notation, we would disallow more > > characters in property values, which we'd really want to avoid. I do > > not know a good solution for this. Ideally, something like #arraymap > > would solve the problem in a modular way, but we would still need at > > least one base syntax for a non-MW separator symbol that would then > > become unavailable in property values. One could make this > > configurable to avoid the problem, but then one needs additional > > syntax that is likely to make everything more complicated. Any > > syntax proposals? > > > > It would be easier to add multiple values to a subobject that has a > > name. The problem here is that due to the use of anonymous > > subobjects, one needs to add all the data within one parser function > > call, and MW just does not support dynamic numbers of parser > > function parameters based on nested template or parser function code. > > > > Markus > > > > > > > > > > > > > > -- > > WikiWorks · MediaWiki Consulting · http://wikiworks.com > > |