Re: [SMW-devel] Modern chat solution as alternative to IRC?
Hi, The history log is not down, but it moved, to this URL: http://bots.wmflabs.org/~wm-bot/logs/%23semantic-mediawiki/ Hopefully someone can change the URL in the message - it has been incorrect for years now, which I'm sure has caused a lot of confusion. I have no strong opinion on the IRC/Gitter/Slack/etc. question. -Yaron On Thu, Jul 27, 2017 at 9:30 AM, Samuel Lampawrote: > On 2017-07-27 14:24, Samuel Lampa wrote: > >> 1) They make history available at all times, even though you weren't >> logged in all the time. This helps users be able to jump in on a question >> asked a few hours ago, while you might have been offline (for time zone >> reasons or whatnot). >> > > On a related note, the current IRC history log seems to be down: > > http://ur1.ca/9gmt7 , which points to http://bots.wmflabs.org/~petrb > /logs/%23semantic-mediawiki/ , returns a 404 page. > > > Best > // Samuel > > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Getting the html code of a wiki page in a maintenance script through the use of Parser.php
Hi Viktor, Someone may answer your question here, but if not, I would suggest writing the mediawiki-l mailing list instead, since it seems to just be a core MediaWiki question. -Yaron On Thu, Dec 15, 2016 at 6:51 AM, Viktorwrote: > Dear developers, > > > I’m having problems getting the correctly parsed html code of a wiki page > stored in a php object (used in a maintenance script). The html output in > my php code has errors in it. The wiki page, which consists of a variety of > templates, parser functions, SMW queries, etc, works fine in the browser. > > This is the code I'm using to get the html: > > > class Mailer extends Maintenance { > > public function execute() { > > //Create parser > $parser = new Parser(); > $user = User::newFromName ('User:Admin', $validate= 'valid'); > $parserOptions = new ParserOptions( $user , 'en' ); > > // Get wiki page html > $title = Title::newFromText( $titleString ); //Title string is the wiki > page which I'm trying to convert to properly parsed html code > $wikiPage = WikiPage::factory( $title ); > $wikiText = $wikiPage->getText(Revision::RAW); > $parserOutput = $parser->parse($wikiText, $title, $parserOptions); > $body = $parserOutput->getText(); > > > My guess is that Parser.php fails to parse multiple levels of the page > syntax, which it has to because of the transcluded templates and parser > functions used on the page. > > Can anyone point me in the right direction as to what goes wrong with my > usage of Parser.php to get the html code of a wiki page? > > > Kind regards, > Viktor Schelling > > > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [Semediawiki-user] SRF: Timeline and Histopedia
Hi Bernhard, I don't mean to needlessly draw out this discussion, but I think it would help if you were more specific - there are a lot of timeline JS libraries out there, and it would be good to know what people consider the most important features. What do you mean by "modern style" - the use of colors? A bigger display? By "responsiveness", do you mean that Exhibit Timeline can be slow to scroll? I hadn't noticed any particular slowness, but it might depend on the number of points loaded. -Yaron On Wed, Oct 5, 2016 at 10:05 AM, Krabina Bernhard <krab...@kdz.or.at> wrote: > Hi Yaron, > > that's a good question. Basically I'd like to see the existing > functionality from the exhibit timeline/eventline in a more modern style > (and probably also better responsiveness). Futhermore both of the others > (histropedia and chap) feature the display of pictures on the timeline, > which of course is also nice to have. > > cheers, > Bernhard > > - Am 4. Okt 2016 um 15:09 schrieb Yaron Koren <ya...@wikiworks.com>: > > > Hi Bernhard, > > Could you enumerate what features you would ideally like to see in a > timeline > > format? The Exhibit Timeline library, which is used by SMW (and, let me > note, > > by Cargo as well), is indeed old and poorly-maintained, but it still > works > > fine. I'm guessing that you would also prefer the Histropedia and CHAP > Timeline > > libraries because of their different displays (such as showing an image > for > > each event) and/or additional features, though I could be wrong. > > > -Yaron > > > On Tue, Oct 4, 2016 at 4:28 AM, Krabina Bernhard < krab...@kdz.or.at > > wrote: > > >> Dear all, > > >> I wrote to the Histopedia team if it was possible to get some kind of > histopedia > >> result format for SMW. The problem with the timeline and eventline > formats is > >> that they are very old and not maintained. > > >> Here is some snippets of what they wrote me: > > >> "We've recently released a JavaScript library called HistropediaJS, > which allows > >> you to use any data source with the Histropedia timeline engine. The > basic > >> licence is free for non-commercial use, including the right to edit the > code > >> where advanced customisation is required (most simple customisation can > be done > >> with the built in options). Is this licence permissive enough for use > in SMW > >> wikis? We do plan on open sourcing at some point, but not sure of the > timescale > >> yet as we need to get a bit further with our business model first. p.s. > Very > >> happy to offer any advise/assistance needed in using HistropediaJS" > > >> So my questions to the SMW developers: > >> 1. Is anybody interested in developing a new result format based on > >> Histopedia.js > >> 2. Is anybody interested in taking over > >> https://www.mediawiki.org/wiki/Extension:ChapTimeline - another > abandoned > >> approach on prividing a new timeline format > >> 3. Is anybody interested in doing another sort of current > timline/eventline > >> format > > >> I am happy to connect you with the Histopedia person. > > >> To the users/organisations: is anybody interested in this and can put > up some > >> funding? > > >> cheers, > >> Bernhard > > >> > -- > >> Check out the vibrant tech community on one of the world's most > >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot > >> ___ > >> Semediawiki-user mailing list > >> semediawiki-u...@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > > -- > > WikiWorks · MediaWiki Consulting · http://wikiworks.com > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Semediawiki-user mailing list > semediawiki-u...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [Semediawiki-user] SRF: Timeline and Histopedia
Hi Bernhard, Could you enumerate what features you would ideally like to see in a timeline format? The Exhibit Timeline library, which is used by SMW (and, let me note, by Cargo as well), is indeed old and poorly-maintained, but it still works fine. I'm guessing that you would also prefer the Histropedia and CHAP Timeline libraries because of their different displays (such as showing an image for each event) and/or additional features, though I could be wrong. -Yaron On Tue, Oct 4, 2016 at 4:28 AM, Krabina Bernhardwrote: > Dear all, > > I wrote to the Histopedia team if it was possible to get some kind of > histopedia result format for SMW. The problem with the timeline and > eventline formats is that they are very old and not maintained. > > Here is some snippets of what they wrote me: > > "We've recently released a JavaScript library called HistropediaJS, which > allows you to use any data source with the Histropedia timeline engine. The > basic licence is free for non-commercial use, including the right to edit > the code where advanced customisation is required (most simple > customisation can be done with the built in options). Is this licence > permissive enough for use in SMW wikis? We do plan on open sourcing at some > point, but not sure of the timescale yet as we need to get a bit further > with our business model first. p.s. Very happy to offer any > advise/assistance needed in using HistropediaJS" > > So my questions to the SMW developers: > 1. Is anybody interested in developing a new result format based on > Histopedia.js > 2. Is anybody interested in taking over https://www.mediawiki.org/ > wiki/Extension:ChapTimeline - another abandoned approach on prividing a > new timeline format > 3. Is anybody interested in doing another sort of current > timline/eventline format > > I am happy to connect you with the Histopedia person. > > To the users/organisations: is anybody interested in this and can put up > some funding? > > cheers, > Bernhard > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Semediawiki-user mailing list > semediawiki-u...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] ApprovedRevs + SMW
That's certainly not intended behavior. Is the page displaying correctly, i.e. blank? And can you find by searching on its contents from Special:Search? (Hopefully not.) Also, I'd recommend upgrading to the latest Approved Revs version, 0.7.1 - who knows, that might be a bug that got fixed. On Fri, Apr 29, 2016 at 4:33 PM, Vedmakawrote: > Hi, Guys! > > I did not touch ApprovedRevs for long time, so, maybe, I forgot some > details, but recently i was surprised a bit: > > I am using MW 1.25.1 + SMW 2.3.1 + ApprovedRevs 0.7 (REL1_25 branch) > ApprovedRevs configured with $egApprovedRevsBlankIfUnapproved = true; > > Once i create or edit page (as normal user, without auto-approve rights) > with some semantic property inside and go to Special:Browse - i see all > my changes there in factbox. It seems like ApprovedRevs did not affect > SMW anyhow - all changes get passed to SMW, so my edit reflects in all > ask-queries. > > This seems very strange for me, can someone confirm - is it a bug or > intended behavior? > > > > -- > Find and fix application performance issues faster with Applications > Manager > Applications Manager provides deep performance insights into multiple > tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > ___ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Set SMW property in extension
Hi, James - note that this is the SMW developers mailing list; I don't think that question is too technical for here. (GitHub might be the better place for it, but I don't want to scare anyone off this list.) -Yaron On Fri, Oct 9, 2015 at 8:26 AM, James HKwrote: > Hi, > > Please open an issue at [0] as the mailing-list is a rather > inappropriate forum for such technical question. > > [0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/ > > Cheers > > On 10/9/15, Dornblut, Nils (Bundeswehr) wrote: > > Hi SMW community, > > > > About 5 years before we have developed a custom MW tag extension to > > create flowcharts. For this purpose we use a self-defined domain > > specific language to create process diagrams with links to other > > articles. As the result, we get an image-map consisting of image and > > HTML code generated. This will displayed on the wiki page. In addition, > > certain semantic properties deposited on the side that can't appear > > directly in the source code of the page. We have had no problem with > > reload or refreshing the page. The properties were always there and were > > always stored correctly. > > > > We use the following code: > > > > SMWParseData::addProperty("Has product", > > $value, > > false, // No caption > > self::$wikiParser, // Mediawiki parser > > true ); // Store data in the database > > > > Problem: http://semantic-mediawiki.org/doc/classSMWParseData.html > > > > THIS CLASS IS OBSOLETE AND SHOULD NOT BE USED BEYOND SMW 1.8. THIS CLASS > > WILL BE REMOVED IN SMW 1.10. > > > > Therefore, we need an alternative. Do you know an code-example for that > > case? Or do we have to use SMW code and parse via the MW-parser? > > > > Thanks! > > > > Nils > > > > > > > -- > > ___ > > Semediawiki-devel mailing list > > Semediawiki-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > -- > ___ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] Fwd: [MediaWiki-l] Fwd: [Wikitech-l] Join the Wikimedia Developer Summit 2016
Seems pretty interesting... I assume this will focus mostly on core MediaWiki and WMF software like VisualEditor and Flow, but apparently not exclusively. -Yaron -- Forwarded message -- From: Quim GilDate: Tue, Sep 15, 2015 at 7:52 AM Subject: [MediaWiki-l] Fwd: [Wikitech-l] Join the Wikimedia Developer Summit 2016 To: MediaWiki announcements and site admin list < mediawik...@lists.wikimedia.org> Hi, the MediaWiki Stakeholders Group, the MediaWiki Farmers User Group, and just anybody involved in MediaWiki development is invited to participate at the Wikimedia Developer Summit 2016. See the details and deadlines below, and please help spreading the word. -- Forwarded message -- From: Rachel Farrand Date: Mon, Sep 14, 2015 at 8:05 PM Subject: [Wikitech-l] Join the Wikimedia Developer Summit 2016 To: Wikimedia developers Hello! The Wikimedia Developer Summit 2016 will be taking place in San Francisco, CA between January 4th and January 6th, 2016. Registration is open along with the call for participation. *Deadline for travel sponsorship requests and the call for participation is October 2, 2015.* https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016 Hope to see you in San Francisco! ___ Wikitech-l mailing list wikitec...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Set a SMW property programmatically in PHP?
Hi Jason, If you're talking about making a change to the semantic data of a page that is not reflected in that page's wikitext, that sounds like a bad idea - the new data would be removed as soon as the page was edited and saved again. -Yaron On Thu, Jun 25, 2015 at 3:42 PM, Jason Ji jason.y...@gmail.com wrote: Hi SMW community, I have a hopefully simple question. Is there a way to set an SMW property for a page programmatically in PHP? Suppose I have access to any of the relevant information, like the page ID. For context, I'm writing an extension which, among other things, creates wiki pages using $wikipage-doEditContent(), and I'd like to be able to set a semantic title https://www.mediawiki.org/wiki/Extension:Semantic_Title property on the page at that point. Thanks! -- Jason Ji jason.y...@gmail.com -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] SemanticForms - formredlink - link text ignored when target exists
Oh, that's interesting. I was envisioning that the link text could look like Create this page, as I noted in my previous email. Perhaps it would be ideal to have two different link text parameters for #formredlink, for use when the page either does or doesn't exist. On Fri, May 29, 2015 at 12:19 PM, Hermann Schwärzler hermann.schwaerz...@uibk.ac.at wrote: Hi Yaron, probably I am doing things not in the best possible way. :-) This is my use-case: I have images that have a page where a title and up to three keywords can be assigned to them. For the keywords I have a custom namespace Keyword (to avoid possible name clashes with image-page titles). In the image-page template I show the keywords like this: {{#formredlink:target=Keyword:{{{keyword1}}}|link text={{{keyword1}}}|form=Keyword}} That means that for not yet existing keywords I see a red-link with the keyword as link-text. For existing keywords I see a blue link with Keyword:keyword as link-text because my link text parameter is ignored and the target parameter is used in this case - which looks ugly and is not the way I think it should be. I found this strange and made the change to the code. How else could I get what I want (to see just the keyword with a link to the keyword-page in the Keyword-namespace)? To turn the tables: What's the use case for the way it is right now? The information about the existence of the page the link points to is already encoded in the colour of the link, isn't it? Greetings Hermann On 05/29/2015 12:49 AM, Yaron Koren wrote: Hi Hermann, That was done on purpose - the idea was that #formredlink has two different behaviors, depending on whether or not the page in question exists. If it doesn't, then of course you see a red link, pointing to a form, with text that possibly looks like Create this page. If it does, then there's just a normal link to that page, and users wouldn't know that there's anything special going on behind the scenes. What's your use case for wanting the same link text to show up whether or not the page exists? And what could such text be? -Yaron [...] -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] SemanticForms - formredlink - link text ignored when target exists
Hi Hermann, That was done on purpose - the idea was that #formredlink has two different behaviors, depending on whether or not the page in question exists. If it doesn't, then of course you see a red link, pointing to a form, with text that possibly looks like Create this page. If it does, then there's just a normal link to that page, and users wouldn't know that there's anything special going on behind the scenes. What's your use case for wanting the same link text to show up whether or not the page exists? And what could such text be? -Yaron On Thu, May 28, 2015 at 10:24 AM, Hermann Schwärzler hermann.schwaerz...@uibk.ac.at wrote: Hi, while using the link text parameter of #formredlink I noticed that this parameter gets ignored when the page specified in the target parameter exists. The shortcut in the code for this case returns Linker::link( $targetTitle ) i.e. without specifying a link text which in turn causes Linker::link to use $targetTitle as link text. Find attached a small patch that solved the problem for me. I am not sure if the htmlspecialchars() call is really necessary but I guess it doesn't hurt, does it? Greetings Hermann -- ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] cargo's page values link
I'm guessing that it's possible, yes. I hadn't really considered that possibility, though there certainly is an argument for doing it that way. I should note that Browse properties, too, shows up for pages that contain no properties - for those namespaces where SMW is enabled. Not that that's necessarily a reason for doing the same thing with Cargo. On Fri, Apr 3, 2015 at 4:22 PM, John McClure jmccl...@hypergrove.com wrote: It would be nice if it only showed on pages for which it applies - is that possible? On 4/3/2015 1:20 PM, Yaron Koren wrote: Hi, Er... no? I didn't think it was a big deal; it's an exact analogue of SMW's browse properties link. -Yaron Is it necessary that Cargo clutter all pages in a wiki with a page values link? -- thanks/john skype:hypergrove -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- thanks/john skype:hypergrove -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] cargo's page values link
Hi, Er... no? I didn't think it was a big deal; it's an exact analogue of SMW's browse properties link. -Yaron Is it necessary that Cargo clutter all pages in a wiki with a page values link? -- thanks/john skype:hypergrove -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] cargo syntax
Actually, #cargo_declare follows the standard syntax for MediaWiki parser functions - usually, either all the parameters are named, or none of them are. #ask is an exception, and #subobject is the very rare exception where the first parameter is often blank (i.e., your last example). -Yaron On Tue, Mar 31, 2015 at 3:36 PM, John McClure jmccl...@hypergrove.com wrote: The first parameter in the following syntax seems error-prone. {{#cargo_declare: _table=table name |field 1=field description 1 |field 2=field description 2 ...etc. }} Normally mediawiki parser functions are either {#cargo_declare: table name |field 1=field description 1 |field 2=field description 2 ...etc. }} {#cargo_declare: |_table=table name |field 1=field description 1 |field 2=field description 2 ...etc. }} I know/agree that{{#set}} is different. -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] cargo issues
Hi, Ah, I didn't think about multiple wikis using the same database. I just checked in a fix so that the prefix for Cargo tables is not $wgDBprefix + cargo__, instead of just cargo__. Each template that stores data needs its own #cargo_declare call. If more than one template stores data to the same table (which may be what you're asking about), then one needs #cargo_declare, and the rest need #cargo_attach. On Tue, Mar 31, 2015 at 2:06 PM, John McClure jmccl...@hypergrove.com wrote: If there are multiple templates that store data, which one does the declare go into? If any, that is it doesn't matter which, then is this constraint you're imposing actually necessary? thanks On 3/31/2015 11:00 AM, Yaron Koren wrote: Oh, I missed your other question - Cargo is built around templates; they are responsible for storing data, so it made sense to put both the table declaration and the table storage go into the template page. -- thanks/john skype:hypergrove -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] cargo issues
Oh, I missed your other question - Cargo is built around templates; they are responsible for storing data, so it made sense to put both the table declaration and the table storage go into the template page. On Tue, Mar 31, 2015 at 1:47 PM, Yaron Koren ya...@wikiworks.com wrote: Hi John, How does the absence of the main MediaWiki DB prefix affect the running of the wiki farm - are you using one database for all the wikis, with a different table prefix for each? And why do you want leading underscores in Cargo table names? -Yaron On Tue, Mar 31, 2015 at 1:17 PM, John McClure jmccl...@hypergrove.com wrote: Hi Yaron I am unable to use Cargo in wikifarms (or with prefixed tables of any sort for that matter) It appears $wgDBprefix is not used in Cargo code, rather it uses its own prefix Cargo__ (?) Also plz do not prevent table names with leading underscores. thanks/john -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] cargo issues
Hi John, How does the absence of the main MediaWiki DB prefix affect the running of the wiki farm - are you using one database for all the wikis, with a different table prefix for each? And why do you want leading underscores in Cargo table names? -Yaron On Tue, Mar 31, 2015 at 1:17 PM, John McClure jmccl...@hypergrove.com wrote: Hi Yaron I am unable to use Cargo in wikifarms (or with prefixed tables of any sort for that matter) It appears $wgDBprefix is not used in Cargo code, rather it uses its own prefix Cargo__ (?) Also plz do not prevent table names with leading underscores. thanks/john -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] cargo syntax
Hi, I don't know what you mean by the vertical bar thing. Again, most MediaWiki parser functions take either the form: {{#function_name:a|b|c}} ...or: {{#function_name:a=b|c=d|e=f}} #cargo_declare takes the latter form; and the parameters can actually go in any order. -Yaron On Tue, Mar 31, 2015 at 5:22 PM, John McClure jmccl...@hypergrove.com wrote: Hi Yaron, To the user, 'field_x' looks and acts like a named parameter. And to the user, _table is even more so a named parameter, as it is predefined by the extension. But to the user, this _table parameter appears to be missing a vertical-bar. And of course a vertical-bar *can* precede that name=value, but the documentation says not to have one. So it's a source of confusion, to the user. (As an aside, parameters with leading underscores are undesirable as well, as they're unconventional.) So a simple {{#cargo_declare: tablename}} would seem to be an easy solution. thanks/john On 3/31/2015 12:46 PM, Yaron Koren wrote: Actually, #cargo_declare follows the standard syntax for MediaWiki parser functions - usually, either all the parameters are named, or none of them are. #ask is an exception, and #subobject is the very rare exception where the first parameter is often blank (i.e., your last example). -Yaron On Tue, Mar 31, 2015 at 3:36 PM, John McClure jmccl...@hypergrove.com wrote: The first parameter in the following syntax seems error-prone. {{#cargo_declare: _table=table name |field 1=field description 1 |field 2=field description 2 ...etc. }} Normally mediawiki parser functions are either {#cargo_declare: table name |field 1=field description 1 |field 2=field description 2 ...etc. }} {#cargo_declare: |_table=table name |field 1=field description 1 |field 2=field description 2 ...etc. }} I know/agree that{{#set}} is different. -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- thanks/john skype:hypergrove -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] queryformlink, input type
Hi Erika, When you use link type=button, it creates a form tag within the HTML, and I'm guessing that it in some way conflicts with the overall form tag of the query form. I don't know why you're linking to a query form from within a query form, but I guess that's a separate issue. -Yaron On Thu, Mar 26, 2015 at 5:50 AM, Griechisch Erika griechisch.er...@med.u-szeged.hu wrote: Dear all, After few months of trying I stilfeel l am new in SMW, I hope I can explain clearly my problem and show the necessary details. First of all I use* SMW 2.0* I created a form and wanted to add to buttons to the top of the form. Part of the Form page code is this (the whole Form code is available here: http://pastebin.com/YCep9aSu) includeonly {{{info|query form at top}}} {{{standard input|run query}}} {{#queryformlink:form=Lekérdezés|link text=Új lekérdezés|tooltip=Törölve a feltételeket, új lekérdezés indítása|link type=button}} {{{for template|Lekérdezés}}} If I remove the link type=button the link is a normal link and it works. If I use the form code above it does not work! The button belongs to the {{{standard input|run query}}} behaves different, if I click on it, it just refreshes the page without running the actual query and clears all settings which was done. Any idea what I am doing wrong? Thanks, Erika Griechisch -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] queryformlink, input type
Hi Erika, Yes - I've avoided clear/reset buttons in forms, because of this advice: http://www.nngroup.com/articles/reset-and-cancel-buttons/ However, the #queryformlink approach would work - you just need to have it be a link, not a button. (Though you could probably use CSS to display the link as a button - I don't know if it's worth the effort.) -Yaron On Thu, Mar 26, 2015 at 9:26 AM, griechisch.er...@med.u-szeged.hu wrote: Hi Yaron, I did not specifically wanted to link to a query form, I only wanted to add a button which clears the form settings. First I tried the suggested way using {{{standard input|cancel}}} but when I inserted it to the form, it did not make any changes, neither the {{{standard input|changes}}} . Do I need to change other things on the form to make it work? Or I completely misunderstand something? Erika On 2015-03-26 13:57, Yaron Koren wrote: Hi Erika, When you use link type=button, it creates a tag within the HTML, and I'm guessing that it in some way conflicts with the overall tag of the query form. I don't know why you're linking to a query form from within a query form, but I guess that's a separate issue. -Yaron On Thu, Mar 26, 2015 at 5:50 AM, Griechisch Erika wrote: Dear all, After few months of trying I stilfeel l am new in SMW, I hope I can explain clearly my problem and show the necessary details. First of all I use SMW 2.0 I created a form and wanted to add to buttons to the top of the form. Part of the Form page code is this (the whole Form code is available here: http://pastebin.com/YCep9aSu [1]) {{{info|query form at top}}} {{{standard input|run query}}} {{#queryformlink:form=Lekérdezés|link text=Új lekérdezés|tooltip=Törölve a feltételeket, új lekérdezés indítása|link type=button}} {{{for template|Lekérdezés}}} If I remove the link type=button the link is a normal link and it works. If I use the form code above it does not work! The button belongs to the {{{standard input|run query}}} behaves different, if I click on it, it just refreshes the page without running the actual query and clears all settings which was done. Any idea what I am doing wrong? Thanks, Erika Griechisch -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ [2] ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net [3] https://lists.sourceforge.net/lists/listinfo/semediawiki-devel [4] -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Add Another stopped working
That is ominous... I should have also suggested adding debug=true to the URL, which might make it clearer where the error is coming from. If that doesn't help, my usual checklist is to try switching to Vector (if you're using a custom skin), and temporarily disable all extensions except for Semantic MediaWiki and Semantic Forms, to see if the problem is coming from the skin or another extension. On Thu, Nov 13, 2014 at 11:04 AM, Sal Quintanilla salqu...@gmail.com wrote: Hi Yaron, Today I'm seeing an ominous Member not found error on line 2764 of load.php, jQuery.valHooks.button.set, referring to ret.nodeValue being null and on the left side of an assignment. Sal -- From: Yaron Koren ya...@wikiworks.com Sent: 11/13/2014 10:45 AM To: Sal Quintanilla salqu...@gmail.com Cc: Semantic MediaWiki developers semediawiki-devel@lists.sourceforge.net Subject: Re: [SMW-devel] Add Another stopped working Hi Sal, When the Add another button works, it's usually a sign that there's some other, unrelated Javascript error that happened. Can you look in the Javascript console, if you know how to do that, and see if there are any error messages there? -Yaron On Thu, Nov 13, 2014 at 10:18 AM, Sal Quintanilla salqu...@gmail.com wrote: Hi Folks, I haven't written in a while. I'm with a new company that had mediawiki before I showed up, which is great. Specifically, they're running: MediaWiki 1.19.5-1 PHP 5.4.4-14+deb7u3 (apache2handler) MySQL 5.5.31-0+wheezy1 I added Semantic Bundle (Version 1.8.0.5), with Semantic MediaWiki (Version 1.8.0.5) Semantic Forms (Version 2.5.3) This version of the bundle came out closer to the time of MW 1.19.5 than the other bundle versions. I did this a couple days ago. I created a quick class and some multiple templates, and it worked fine as of yesterday. Today, one the same test forms, the Add Another button doesn't work, it just sits there. I did a brand new multiple instance template and form to make sure I didn't do something I forgot, but the Add Another button in the generated form also doesn't work, so I believe syntax is correct. I read through Semantic Forms/Common Problems, http://www.mediawiki.org/wiki/Extension:Semantic_Forms/Common_problems but it didn't get me past this... and the other issues I found about this not working were about much earlier versions of MW. Add Another works on some Discourse forms, so my browser (IE 11) is ok. Q: Any ideas what may have gone wrong? Q: Is there a later version of Semantic Bundle that would work with 1.19.5? Thanks as always. Sal -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [Semediawiki-user] smw.referata.org vs. smw.org (Was: Exclude specific pages from query or #Concept?)
Hi, There's actually not that much overlap between smw.referata.com and semantic-mediawiki.org at the moment. smw.referata.com contains pages on the following: - People who use or develop SMW - Companies that use or work with SMW - Sites that use SMW - Events that have an SMW component - Software packages that include SMW - Tips on using SMW Each of these has its own form/template data structure, as you might imagine. As far as I know, there is no direct equivalent for any of these on semantic-mediawiki.org, though some of the information in the tips can also be found on s-mw.org. Of all of these page types, probably the strongest case could be made for moving tips over to s-mw.org, although a case could be made for moving all of them over. If anyone wants to create a corresponding data structure on s-mw.org for any of these page types, I'd be happy to help move the content over, and then make a bunch of redirects on smw.referata.com. -Yaron -- ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [SF] Embedded Special:RunQuery creates strange charaters
Hi, Just to clarify, this is not related to the TreeAndMenu extension, which is not installed on Referata. Rather, the issue is that there was a change in the Semantic Forms code around (I think) six months ago, that changed the way forms were parsed - it improved some things, but had the unfortunate side effect of making Special:RunQuery not embeddable in most cases. Hopefully this issue can be resolved. -Yaron On Wed, Oct 8, 2014 at 4:10 AM, planetenxin planeten...@web.de wrote: I found another hint that may help debugging: https://www.mediawiki.org/wiki/Extension_talk:NewPageCSS#Outputs_nonsense Am 08.10.2014 08:20, schrieb planetenxin: Hi, embedded {{Special:RunQuery/Map_query}} creates strange characters like UNIQ225794f6d43c6688-h-0--QINU before headings or with {{#tree:}} parser function from Extension:TreeAndMenu. I'd guess that there are also other cases where this happens. Example: http://scratchpad.referata.com/wiki/Test_TreeAndQuery Any ideas? /Alexander -- semantic::apps by gesinn.it Business Applications with Semantic Mediawiki. http://semantic-apps.com -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [Semediawiki-user] MediaWiki Job queue problem
Hi, I believe the issue is the job_attempts field in the job table. I believe each job is only attempted a certain number of times before MediaWiki basically just gives up and ignores it. My guess is that that column is greater than 0 for all the rows in the table; I think if you just go into the database and call something like UPDATE job SET job_attempts = 0, they will get run again. -Yaron -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Accessing Semantic Forms fields from within form input
Hi Yury, Well, each form input's own file (contained in /includes/forminputs) contains a getHTML() method, which in turn has a $cur_value parameter that holds the current value. All those getHTML() methods are called from SFFormPrinter::formHTML(), a monstrously large method that's really the heart of Semantic Forms. Look for the variables $cur_value and $cur_value_in_template in that function. -Yaron On Tue, Jul 29, 2014 at 10:39 AM, Yury Katkov katkov.ju...@gmail.com wrote: Yes, that kind of autocomplatetion might require some kind of custom Javascript solutio I'm trying to develop exactly that. For now I'm able to load the list of option tags for all my dropdown, but I can't figure out, how to initialize my dropdown with the current value. Yaron, what function populates forms inputs with the current values (taken from templates)? - Yury Katkov On Wed, Jul 23, 2014 at 12:44 AM, Yaron Koren ya...@wikiworks.com wrote: Hi Yury, Oh... that's a lot of files! Yes, that kind of autocomplatetion might require some kind of custom Javascript solution. Although, if the goal is to have a wiki page for each of those files, another option is to just create a page for each file automatically, with the first 2-4 of those template fields already filled in. You could do that with the Data Transfer extension, or a custom script; the latter might be better, given the massive size of the data. -Yaron On Tue, Jul 22, 2014 at 12:43 PM, Yury Katkov katkov.ju...@gmail.com wrote: Hi Yaron! (First, it doesn't matter that much, but this question should probably have been sent to the SMW users list.) Sorry... I thought it requires the creation of form input or patching the SF, so I asked it here. Thanks for the way, but it will not work for me because: 1) we will probably have 50-100 servers 2) each of the servers will have lot's of files: sometimes several terabytes of 10M images. That's a lot. 3) I've used the example for the file server and it's my current need/ However I'm very interested in a generic API calls from withing the semantic form when we put some data in the form and sending the ajax call to an api with our current field values as the parameters. for now I will try to solve this with javascript extension that listens the blur() action and the REST-API that is responsible for delivering the information - Yury Katkov On Tue, Jul 22, 2014 at 4:09 PM, Yaron Koren ya...@wikiworks.com wrote: Hi Yury, (First, it doesn't matter that much, but this question should probably have been sent to the SMW users list.) You didn't explicitly say it, but I'm guessing that (a) the set of file names to be autocompleted on is all the files contained in that file server, and (b) this information is not stored anywhere in the wiki. Assuming that, I think there's a way to do this, but it takes some work, and it's a hack. First, you'd need to write some web-based script, outside of the wiki, that, when you go to the URL for that script, outputs a table with two columns: a server name and a file name; containing the entire list of all the relevant files and of course the server for each. It can be done as CSV, XML or JSON, though I would think the easiest way to do it would be as CSV. Then you should install the External Data extension, if you don't have it already, and, in one page in the wiki (it can be any page), have a call to #get_web_data and then #store_external_table, so that all of that data gets stored as subobjects. It's important that the #store_external_table call uses the same semantic properties that are used in the template. So if your template has properties like Has server and Has filename, the #store_external_table call should look something like: {{#store_external_table:Server-file pair |Has server={{{server}}} |Has filename={{{file}}} }} (The property name in the first argument doesn't matter.) Now, within the form, you just need to use values dependent on within the Filename field. Let's say that the template is called File information, and the first two template fields are Server and Filename. The Filename field tag in the form might look like: {{{field|Filename|input type=text with autocomplete|values dependent on=File information[Server]}}} ...and hopefully that will work. Who knows, stranger things have happened. :) What makes this more of a hack is that the wiki page with the #store_external_table call will need to have its data regularly refreshed in order to capture any changes to the set of files. That can be done by resaving the page, or calling an SMW data refresh in some way. -Yaron On Tue, Jul 22, 2014 at 5:45 AM, Yury Katkov katkov.ju...@gmail.com wrote: Hi Yaron, everyone! Very often I need to perform some actions while being inside the form. For example right now I have this form: http://i.imgur.com/cYNHSFN.png I need the following behavior: 1) User picks the file server from
Re: [SMW-devel] Accessing Semantic Forms fields from within form input
Hi Yury, How the current value is specifically set depends on which input it is... but the inputs themselves don't know anything other than the parameters that they're called with (which should be enough, of course). -Yaron On Tue, Jul 29, 2014 at 3:12 PM, Yury Katkov katkov.ju...@gmail.com wrote: Hi! This part I know. But I meant the javascript side - how the current value is loaded there? Is there a method that allows me to retrieve the current template field value whil I'm in js? - Yury Katkov On Tue, Jul 29, 2014 at 5:49 PM, Yaron Koren ya...@wikiworks.com wrote: Hi Yury, Well, each form input's own file (contained in /includes/forminputs) contains a getHTML() method, which in turn has a $cur_value parameter that holds the current value. All those getHTML() methods are called from SFFormPrinter::formHTML(), a monstrously large method that's really the heart of Semantic Forms. Look for the variables $cur_value and $cur_value_in_template in that function. -Yaron On Tue, Jul 29, 2014 at 10:39 AM, Yury Katkov katkov.ju...@gmail.com wrote: Yes, that kind of autocomplatetion might require some kind of custom Javascript solutio I'm trying to develop exactly that. For now I'm able to load the list of option tags for all my dropdown, but I can't figure out, how to initialize my dropdown with the current value. Yaron, what function populates forms inputs with the current values (taken from templates)? - Yury Katkov On Wed, Jul 23, 2014 at 12:44 AM, Yaron Koren ya...@wikiworks.com wrote: Hi Yury, Oh... that's a lot of files! Yes, that kind of autocomplatetion might require some kind of custom Javascript solution. Although, if the goal is to have a wiki page for each of those files, another option is to just create a page for each file automatically, with the first 2-4 of those template fields already filled in. You could do that with the Data Transfer extension, or a custom script; the latter might be better, given the massive size of the data. -Yaron On Tue, Jul 22, 2014 at 12:43 PM, Yury Katkov katkov.ju...@gmail.com wrote: Hi Yaron! (First, it doesn't matter that much, but this question should probably have been sent to the SMW users list.) Sorry... I thought it requires the creation of form input or patching the SF, so I asked it here. Thanks for the way, but it will not work for me because: 1) we will probably have 50-100 servers 2) each of the servers will have lot's of files: sometimes several terabytes of 10M images. That's a lot. 3) I've used the example for the file server and it's my current need/ However I'm very interested in a generic API calls from withing the semantic form when we put some data in the form and sending the ajax call to an api with our current field values as the parameters. for now I will try to solve this with javascript extension that listens the blur() action and the REST-API that is responsible for delivering the information - Yury Katkov On Tue, Jul 22, 2014 at 4:09 PM, Yaron Koren ya...@wikiworks.com wrote: Hi Yury, (First, it doesn't matter that much, but this question should probably have been sent to the SMW users list.) You didn't explicitly say it, but I'm guessing that (a) the set of file names to be autocompleted on is all the files contained in that file server, and (b) this information is not stored anywhere in the wiki. Assuming that, I think there's a way to do this, but it takes some work, and it's a hack. First, you'd need to write some web-based script, outside of the wiki, that, when you go to the URL for that script, outputs a table with two columns: a server name and a file name; containing the entire list of all the relevant files and of course the server for each. It can be done as CSV, XML or JSON, though I would think the easiest way to do it would be as CSV. Then you should install the External Data extension, if you don't have it already, and, in one page in the wiki (it can be any page), have a call to #get_web_data and then #store_external_table, so that all of that data gets stored as subobjects. It's important that the #store_external_table call uses the same semantic properties that are used in the template. So if your template has properties like Has server and Has filename, the #store_external_table call should look something like: {{#store_external_table:Server-file pair |Has server={{{server}}} |Has filename={{{file}}} }} (The property name in the first argument doesn't matter.) Now, within the form, you just need to use values dependent on within the Filename field. Let's say that the template is called File information, and the first two template fields are Server and Filename. The Filename field tag in the form might look like: {{{field|Filename|input type=text with autocomplete|values dependent on=File information[Server]}}} ...and hopefully that will work. Who knows, stranger things
Re: [SMW-devel] Accessing Semantic Forms fields from within form input
Hi Yury, (First, it doesn't matter that much, but this question should probably have been sent to the SMW users list.) You didn't explicitly say it, but I'm guessing that (a) the set of file names to be autocompleted on is all the files contained in that file server, and (b) this information is not stored anywhere in the wiki. Assuming that, I think there's a way to do this, but it takes some work, and it's a hack. First, you'd need to write some web-based script, outside of the wiki, that, when you go to the URL for that script, outputs a table with two columns: a server name and a file name; containing the entire list of all the relevant files and of course the server for each. It can be done as CSV, XML or JSON, though I would think the easiest way to do it would be as CSV. Then you should install the External Data extension, if you don't have it already, and, in one page in the wiki (it can be any page), have a call to #get_web_data and then #store_external_table, so that all of that data gets stored as subobjects. It's important that the #store_external_table call uses the same semantic properties that are used in the template. So if your template has properties like Has server and Has filename, the #store_external_table call should look something like: {{#store_external_table:Server-file pair |Has server={{{server}}} |Has filename={{{file}}} }} (The property name in the first argument doesn't matter.) Now, within the form, you just need to use values dependent on within the Filename field. Let's say that the template is called File information, and the first two template fields are Server and Filename. The Filename field tag in the form might look like: {{{field|Filename|input type=text with autocomplete|values dependent on=File information[Server]}}} ...and hopefully that will work. Who knows, stranger things have happened. :) What makes this more of a hack is that the wiki page with the #store_external_table call will need to have its data regularly refreshed in order to capture any changes to the set of files. That can be done by resaving the page, or calling an SMW data refresh in some way. -Yaron On Tue, Jul 22, 2014 at 5:45 AM, Yury Katkov katkov.ju...@gmail.com wrote: Hi Yaron, everyone! Very often I need to perform some actions while being inside the form. For example right now I have this form: http://i.imgur.com/cYNHSFN.png I need the following behavior: 1) User picks the file server from the dropdown 2) The form sends the js-query to the server and retrieves the filenames. 3) the Filename field got populated with autocompletion values - possible filenames. How do you think is possible to achieve such behavior? - Yury Katkov -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Accessing Semantic Forms fields from within form input
Hi Yury, Oh... that's a lot of files! Yes, that kind of autocomplatetion might require some kind of custom Javascript solution. Although, if the goal is to have a wiki page for each of those files, another option is to just create a page for each file automatically, with the first 2-4 of those template fields already filled in. You could do that with the Data Transfer extension, or a custom script; the latter might be better, given the massive size of the data. -Yaron On Tue, Jul 22, 2014 at 12:43 PM, Yury Katkov katkov.ju...@gmail.com wrote: Hi Yaron! (First, it doesn't matter that much, but this question should probably have been sent to the SMW users list.) Sorry... I thought it requires the creation of form input or patching the SF, so I asked it here. Thanks for the way, but it will not work for me because: 1) we will probably have 50-100 servers 2) each of the servers will have lot's of files: sometimes several terabytes of 10M images. That's a lot. 3) I've used the example for the file server and it's my current need/ However I'm very interested in a generic API calls from withing the semantic form when we put some data in the form and sending the ajax call to an api with our current field values as the parameters. for now I will try to solve this with javascript extension that listens the blur() action and the REST-API that is responsible for delivering the information - Yury Katkov On Tue, Jul 22, 2014 at 4:09 PM, Yaron Koren ya...@wikiworks.com wrote: Hi Yury, (First, it doesn't matter that much, but this question should probably have been sent to the SMW users list.) You didn't explicitly say it, but I'm guessing that (a) the set of file names to be autocompleted on is all the files contained in that file server, and (b) this information is not stored anywhere in the wiki. Assuming that, I think there's a way to do this, but it takes some work, and it's a hack. First, you'd need to write some web-based script, outside of the wiki, that, when you go to the URL for that script, outputs a table with two columns: a server name and a file name; containing the entire list of all the relevant files and of course the server for each. It can be done as CSV, XML or JSON, though I would think the easiest way to do it would be as CSV. Then you should install the External Data extension, if you don't have it already, and, in one page in the wiki (it can be any page), have a call to #get_web_data and then #store_external_table, so that all of that data gets stored as subobjects. It's important that the #store_external_table call uses the same semantic properties that are used in the template. So if your template has properties like Has server and Has filename, the #store_external_table call should look something like: {{#store_external_table:Server-file pair |Has server={{{server}}} |Has filename={{{file}}} }} (The property name in the first argument doesn't matter.) Now, within the form, you just need to use values dependent on within the Filename field. Let's say that the template is called File information, and the first two template fields are Server and Filename. The Filename field tag in the form might look like: {{{field|Filename|input type=text with autocomplete|values dependent on=File information[Server]}}} ...and hopefully that will work. Who knows, stranger things have happened. :) What makes this more of a hack is that the wiki page with the #store_external_table call will need to have its data regularly refreshed in order to capture any changes to the set of files. That can be done by resaving the page, or calling an SMW data refresh in some way. -Yaron On Tue, Jul 22, 2014 at 5:45 AM, Yury Katkov katkov.ju...@gmail.com wrote: Hi Yaron, everyone! Very often I need to perform some actions while being inside the form. For example right now I have this form: http://i.imgur.com/cYNHSFN.png I need the following behavior: 1) User picks the file server from the dropdown 2) The form sends the js-query to the server and retrieves the filenames. 3) the Filename field got populated with autocompletion values - possible filenames. How do you think is possible to achieve such behavior? - Yury Katkov -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- WikiWorks · MediaWiki Consulting · http://wikiworks.com
Re: [SMW-devel] usage of values from URL
Hi Yury, You should replace substr in that URL with substr - that might just be the issue. However, I should note that we're currently, as part of Jatin Mehta's Google Summer of Code project on SF autocompletion, working on improving autocompletion on external values. Right now the setup is quite limited - you need to basically set up an API that outputs the necessary values in a specific JSON format, unless you happen to be autocompleting on values from another SMW-based wiki. Jatin's project will hopefully expand that considerably, making use of functionality like that of the External Data extension to allow for flexibly getting value sets from a variety of formats. I don't know if you were planning to create such a mini-API already, but, if you're willing to wait a month or two, it could be that that effort would no longer be necessary. -Yaron On Mon, Jul 21, 2014 at 6:06 AM, Yury Katkov katkov.ju...@gmail.com wrote: Hi everyone! I'm trying to figure out how the autocompletion on outside values works. [1] Is that possible to use it for the dropdowns? I'm trying to do that but have no results. I've added this to the LocalSettings.php: $sfgAutocompletionURLs['discourse'] = ' http://discoursedb.org/w/api.php?action=sfautocompletesubstr=newproperty=Was_written_byformat=json '; I've created the following field in the form: {{{field|Was written by|input type=dropdown|values from url=discourse|remote autocompletion}}} I expect that the dropdown will be populated with the values from discoursedb: Bangor Daily News editorial board Gavin Newsom, etc ... but nothing happens. What do I do wrong? [1] https://www.mediawiki.org/wiki/Extension:Semantic_Forms/Autocompleting_on_outside_values - Yury Katkov -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] usage of values from URL
Oops, sorry, you're right - it's the string new in the URL that you should replace with substr. On Mon, Jul 21, 2014 at 11:43 AM, Yury Katkov katkov.ju...@gmail.com wrote: Hi Yaron! You should replace substr in that URL with substr - that might just be the issue. I don't think I should... I don't need any parameters, try to click on the link - it produces perfect results. - Yury Katkov On Mon, Jul 21, 2014 at 4:07 PM, Yaron Koren ya...@wikiworks.com wrote: Hi Yury, You should replace substr in that URL with substr - that might just be the issue. However, I should note that we're currently, as part of Jatin Mehta's Google Summer of Code project on SF autocompletion, working on improving autocompletion on external values. Right now the setup is quite limited - you need to basically set up an API that outputs the necessary values in a specific JSON format, unless you happen to be autocompleting on values from another SMW-based wiki. Jatin's project will hopefully expand that considerably, making use of functionality like that of the External Data extension to allow for flexibly getting value sets from a variety of formats. I don't know if you were planning to create such a mini-API already, but, if you're willing to wait a month or two, it could be that that effort would no longer be necessary. -Yaron On Mon, Jul 21, 2014 at 6:06 AM, Yury Katkov katkov.ju...@gmail.com wrote: Hi everyone! I'm trying to figure out how the autocompletion on outside values works. [1] Is that possible to use it for the dropdowns? I'm trying to do that but have no results. I've added this to the LocalSettings.php: $sfgAutocompletionURLs['discourse'] = ' http://discoursedb.org/w/api.php?action=sfautocompletesubstr=newproperty=Was_written_byformat=json '; I've created the following field in the form: {{{field|Was written by|input type=dropdown|values from url=discourse|remote autocompletion}}} I expect that the dropdown will be populated with the values from discoursedb: Bangor Daily News editorial board Gavin Newsom, etc ... but nothing happens. What do I do wrong? [1] https://www.mediawiki.org/wiki/Extension:Semantic_Forms/Autocompleting_on_outside_values - Yury Katkov -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] usage of values from URL
Alright, I actually tried it out, which I probably should have done at the beginning, and now I'm pretty sure I know what the issue is. You're using input type=dropdown, but values from url only works with the autocompletion input types. I don't know, by the way, if that's a good idea or not - I think my original thought with disallowing dropdown and the like is so that, if there's a drastic change to the set of external values - or if the URL is temporarily inaccessible, or some such - it won't mess up editing of existing values. But perhaps there's an argument to be made the other way. On the other hand, maybe dropdown was a mistake there, and you just meant combobox. On Mon, Jul 21, 2014 at 12:38 PM, Yury Katkov katkov.ju...@gmail.com wrote: my point is that I don't need substr at all. My URL is static and I'm totally satisfied. - Yury Katkov On Mon, Jul 21, 2014 at 5:50 PM, Yaron Koren ya...@wikiworks.com wrote: Oops, sorry, you're right - it's the string new in the URL that you should replace with substr. On Mon, Jul 21, 2014 at 11:43 AM, Yury Katkov katkov.ju...@gmail.com wrote: Hi Yaron! You should replace substr in that URL with substr - that might just be the issue. I don't think I should... I don't need any parameters, try to click on the link - it produces perfect results. - Yury Katkov On Mon, Jul 21, 2014 at 4:07 PM, Yaron Koren ya...@wikiworks.com wrote: Hi Yury, You should replace substr in that URL with substr - that might just be the issue. However, I should note that we're currently, as part of Jatin Mehta's Google Summer of Code project on SF autocompletion, working on improving autocompletion on external values. Right now the setup is quite limited - you need to basically set up an API that outputs the necessary values in a specific JSON format, unless you happen to be autocompleting on values from another SMW-based wiki. Jatin's project will hopefully expand that considerably, making use of functionality like that of the External Data extension to allow for flexibly getting value sets from a variety of formats. I don't know if you were planning to create such a mini-API already, but, if you're willing to wait a month or two, it could be that that effort would no longer be necessary. -Yaron On Mon, Jul 21, 2014 at 6:06 AM, Yury Katkov katkov.ju...@gmail.com wrote: Hi everyone! I'm trying to figure out how the autocompletion on outside values works. [1] Is that possible to use it for the dropdowns? I'm trying to do that but have no results. I've added this to the LocalSettings.php: $sfgAutocompletionURLs['discourse'] = ' http://discoursedb.org/w/api.php?action=sfautocompletesubstr=newproperty=Was_written_byformat=json '; I've created the following field in the form: {{{field|Was written by|input type=dropdown|values from url=discourse|remote autocompletion}}} I expect that the dropdown will be populated with the values from discoursedb: Bangor Daily News editorial board Gavin Newsom, etc ... but nothing happens. What do I do wrong? [1] https://www.mediawiki.org/wiki/Extension:Semantic_Forms/Autocompleting_on_outside_values - Yury Katkov -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Adding Site Settings support to SMW?
Hi James, I'm not a huge fan of such interdependencies (and AdminLinks is no exception). This seems like the most overriding of your objections. Could you elaborate on it? -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Adding Site Settings support to SMW?
Hi Yury, On Wed, Jul 16, 2014 at 1:32 AM, Yury Katkov katkov.ju...@gmail.com wrote: Hi Yaron! I think that for SiteSettings this patch could make sense although I'm strongly against such interdependencies between extensions (after trying to contribute to PageSchemas) Could you expand on that? Is AdminLinks mentioned in SMW? That's really strange and surprising - I thought it's just a header button and the predefined wikipage for the content (well, maybe it can also check, which extensions are installed). Every extension-related link in Special:AdminLinks is added by that extension. -Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Adding Site Settings support to SMW?
Hi Yury, You're right that Page Schemas, unlike the other two, is not really a generic framework, and is pretty tightly integrated in with the standard SMW approach to data structures, which has caused some problems. Personally, I think Page Schemas works well now - I use it on a regular basis - but that of course is a matter of opinion. Like with any software, there's always room for improvement. -Yaron On Wed, Jul 16, 2014 at 10:46 AM, Yury Katkov katkov.ju...@gmail.com wrote: Hi! On Wed, Jul 16, 2014 at 3:37 PM, Yaron Koren ya...@wikiworks.com wrote: Hi Yury, On Wed, Jul 16, 2014 at 1:32 AM, Yury Katkov katkov.ju...@gmail.com wrote: Hi Yaron! I think that for SiteSettings this patch could make sense although I'm strongly against such interdependencies between extensions (after trying to contribute to PageSchemas) Could you expand on that? It's just a lot harder to contribute the code when there is such a dependency. In order to contribute the code I have to make changes not in one extension but in two or three. This can create inconsistency, like the one we can see now in Page Schemas: there are some features that are presented in PS but the code in SF still doesn't have support for them, because the changes haven't been accepted. I understand that you've had in mind the following scenario: there is Page Schemas and everyone can register their own extension in it. It didn't work well in the Page Schemas case but it can in principle work in case of Site Settings since it's not SMW-specific. Is AdminLinks mentioned in SMW? That's really strange and surprising - I thought it's just a header button and the predefined wikipage for the content (well, maybe it can also check, which extensions are installed). Every extension-related link in Special:AdminLinks is added by that extension. -Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Adding Site Settings support to SMW?
Hi John, The Page Schemas class is linked in my original email; the Admin Links function is in SemanticMediaWiki.hooks.php. I would rather not get into the technical details of any of those extensions in this thread, except as it relates to SMW. However - it's true that a key-value approach for Site Settings would be more flexible than a hardcoded table, but Site Settings is also meant to be usable for a wiki farm, and I figured that a standard DB table would be easier for admins to deal with than a big key-value table. -Yaron On Wed, Jul 16, 2014 at 12:27 PM, John McClure jmccl...@hypergrove.com wrote: On 7/15/2014 7:25 PM, Yaron Koren wrote: Semantic MediaWiki already hooks into the first two: Admin Links via a function, and Page Schemas with a class. Hi Yaron - What function/class are those. Also, i happened to review PS extension's DTD - has it changed? ?xml version=1.0 encoding=utf-8? !DOCTYPE PageSchema [ !ELEMENT PageSchema (Template*) !ELEMENT PageSchema (semanticforms_Form*) !ATTLIST PageSchema name CDATA #REQUIRED !ELEMENT Template (Field*) !ATTLIST Template name CDATA #REQUIRED !ATTLIST semanticforms_Form name CDATA #REQUIRED !ATTLIST Field name CDATA #REQUIRED ] I looked at SiteSettings schema and wondering about a different idea -- how about duplicating mediawiki's interwiki table but with a blob of named-value settings. In this way other setup settings can be added with great ease. And it can be used as the anchor for definition of an smw-wiki farm. It could come in handy during cross-site joins in some future. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Adding Site Settings support to SMW?
Hi Jeroen, Unfortunately, there isn't yet a public example of an extension that hooks into Site Settings - if this potential code gets into SMW, SMW could become the first. But the basic idea is that the class would contain various static methods, each of which was called by a different Site Settings hook, that mainly did the following: added HTML for new fields to the Special:SiteSettings form, saved information from those fields to the database, and loaded information from the database into SMW's global variables. The latter two would be done by calling the Site Settings API, for what it's worth - there would be no direct database calls. By the way, the only SMW global variable that I'm currently planning to handle in this code is $smwgShowFactbox - but there's always the potential for adding additional settings. -Yaron On Wed, Jul 16, 2014 at 7:50 PM, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, Can you give me some idea of what this code you'd put in SMW would look like? Is there already an example somewhere? Cheers -- Jeroen De Dauw - http://www.bn2vs.com Software craftsmanship advocate Evil software architect at Wikimedia Germany ~=[,,_,,]:3 -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] Adding Site Settings support to SMW?
Hi, There are three extensions of mine that take a similar approach, where they provide a generic framework and other extensions add their own specific functionality in via hooks: Admin Links, Page Schemas and Site Settings. Semantic MediaWiki already hooks into the first two: Admin Links via a function, and Page Schemas with a class. [1] Site Settings [2] is the newest of these three, and SMW doesn't connect to it yet, but I would like to add code in to SMW to do that, most likely via another class, that would be called SMWSiteSettings. The code that interfaces with Page Schemas caused some controversy before on this mailing list (though the Admin Links code never did), so I thought I'd ask about it here before trying to send in a patch. I'm not planning on adding any testing code for this new code, just like there isn't for the Admin Links and Page Schemas code in SMW; but my philosophy, as I explained before when we talked about Page Schemas, is that, even in the worst case where the code crashes completely, it will not affect any of the other SMW functionality, so it can safely be ignored by SMW developers. I certainly hope to be able to add such a patch in, but I look forward to any questions or comments. [1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/includes/SMW_PageSchemas.php [2] https://www.mediawiki.org/wiki/Extension:Site_Settings -Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Game wikis
Hi John, By game, I assume you're referring to what is usually called workflow. It's true that MediaWiki could have much better support for defining workflow - there's no reason why requesting a page deletion on Wikipedia should require three steps, for instance - but I don't think you'd need to have any sort of workflow framework to have better access control; MediaWiki just needs to more consistently respect existing read permissions. -Yaron On Fri, Jul 11, 2014 at 11:59 AM, John McClure jmccl...@hypergrove.com wrote: Hi Yaron and others I've long thought an essential grounding semantic model is based on the concept of a 'story' what with a resource itself only telling half the story about something (ie open wolrd assumption); stories are a good fit with the wiki model as each page is a 'topic' each tells a story. The challenge has been to extract semantic properties that reflect the whats,who,whys,whens,wheres,etc that the story is or is about. But I think an equally good grounding model is based on the concept of a 'game' -- many things, even wikis, can be characterized this way to good effect. It models things like teams, players, referees, moves and most particularly, rules. The challenge then is to apply semantics during applications of rules and strategies in response to one or more player moves. Game theory in vitro, ya know. It would be interesting if a semantic wiki were structured to operate games in general (plus of course its own 'wiki-game'). Over time patterns of games (and of strategies) would surface -- selected by an admin for a wiki's operation, or by users wishing to create or initiate some knid of 'game' (eg shopping) of their own or to join a game in progress. A 'service orchestration' might be involved, bounded by rules. A 'game' wiki does things like create virtual users who participate (or referee or act as agents) during life of the game. It could establish new rules on the fly, maintain scoring, notify participants, manage the audience, collect tickets and so on. It could radically shorten the time to field customized games by organizations and individuals. 'Games' I hope could also bring about *intrawikis*, that is wikis within a wiki, each game with an ACL. Doing this sort of thing I'd expect to make smw more than just the database application it sometimes appears to be, one whose mission is vulnerable to other semantic database applications I can think of. At some point, SemanticMediaWiki should put semantics INTO mediawiki, not just extract semantic properties from mediawiki pages. We seem prevented though by a common distaste to modify mediawiki core and hence, paralyzed. best/john On 7/9/2014 7:09 PM, Yaron Koren wrote: Hi Peter, On Wed, Jul 9, 2014 at 12:56 PM, Peter Brooks peter.bro...@kchclinics.com wrote: I'm trying to think about this in a more semantic way. Surely, part of the point of semantics is to allow rules to be governed by them. If I could create a property, say '[[page_visibility::group_X]]' then it would make sense for the wiki to understand, from that, that the rule for this property would be found on the property page 'page_visibility' and it could apply those rules to group_X. Does that make sense? I disagree with this - I've stated this opinion before on these mailing lists, but it's important to differentiate between data that applies to the real world, and data that applies to the wiki. The fact that Ulysses was written by James Joyce is real-world data; the fact that the page on the wiki about Ulysses should only be editable or viewable by some people is wiki-specific data. In my opinion, SMW only has an obligation to handle the former: in some cases, it does handle the latter (like all of the special properties relating to page creation), but I view that strictly as a bonus, not an integral part of the software. I don't mean to derail this thread - other people may have more of an opinion on the technical specifics - but I just wanted to note that. -Yaron -- ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [Semediawiki-user] Namespaces
Hi Peter, On Wed, Jul 9, 2014 at 12:56 PM, Peter Brooks peter.bro...@kchclinics.com wrote: I'm trying to think about this in a more semantic way. Surely, part of the point of semantics is to allow rules to be governed by them. If I could create a property, say '[[page_visibility::group_X]]' then it would make sense for the wiki to understand, from that, that the rule for this property would be found on the property page 'page_visibility' and it could apply those rules to group_X. Does that make sense? I disagree with this - I've stated this opinion before on these mailing lists, but it's important to differentiate between data that applies to the real world, and data that applies to the wiki. The fact that Ulysses was written by James Joyce is real-world data; the fact that the page on the wiki about Ulysses should only be editable or viewable by some people is wiki-specific data. In my opinion, SMW only has an obligation to handle the former: in some cases, it does handle the latter (like all of the special properties relating to page creation), but I view that strictly as a bonus, not an integral part of the software. I don't mean to derail this thread - other people may have more of an opinion on the technical specifics - but I just wanted to note that. -Yaron -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Rating system
Hi Ben, It's not clear to me that this would require any development work. It seems to me that you could have an approach like the following: - Have a separate page for each vote; it could be structured as a subpage of the user page, or a subpage of the canyon page, or something else - so it could be called User:Joe User/Big Canyon rating, or Big Canyon/Joe User rating, or Rating of Joe User for Big Canyon or some such. - Each such page would hold a template with a single field, representing the rating number. The user and canyon wouldn't have to be stored on the page, because the template could extract those from the page title. The template would store all three values (canyon, user, rating) as semantic values. - On each canyon page, the template would display the average rating for that canyon, using a semantic query (with the average format), and might also show the number of votes (using count). It would then have a link to a popup form, to let the current user either submit a new rating (if they haven't voted already) or change their rating. You could do that using #formlink, plus the {{CURRENTUSER}} variable from the MyVariables extension. - The ratings input within the popup form, and the average rating display, could both be done using the familiar stars interface, using the Semantic Rating extension (https://www.mediawiki.org/wiki/Extension:Semantic_Rating) This whole thing is somewhat of a hack (a new page for every rating), but maybe not that bad. Of course, it means that users can change each others' ratings, which is not ideal, but then again malicious users can cause all sorts of mischief within a wiki, if they want to - there are already ways of dealing with that. -Yaron On Thu, May 15, 2014 at 10:47 PM, Benjamin Pelletier bjpcalt...@gmail.comwrote: I have a Semantic MediaWiki installation http://ropewiki.com/ that has a large number of Canyon pageshttp://ropewiki.com/index.php/Category:Canyons, where each of those pages describes a different hiking trip. These pageshttp://ropewiki.com/index.php/Havasu_Canyonhave a number of properties on them, one of them being Quality (how good of a trip it is). Currently, editors can edit the wikitext to change this property. I would like make a feature that allows people to vote on what Quality they think a particular Canyon is, and then the overall Quality (based on the votes received) would be displayed on the page. I can think of a few different ways this might be done, but I was hoping to get some advice from people who are really familiar with Semantic MediaWiki for which method is likely to produce the best results with the least effort. == Single Voting data wiki page == I could make an extension that automatically edits a particular wiki page (perhaps Voting data) in response to a click. It would read the existing content, add the new vote, recalculate ratings, generate semantic properties with those ratings, and save the new page version. I'm not sure if this is possible, but it seems like the best solution if it is. Although, there might be a problem eventually if, say, 300 people each vote on 10 canyons, then my page size is going to be like 60k (which may cause performance issues?) == Stand-alone widget == I could make an extension that injects custom PHP that talks to an entirely separate (non-MediaWiki) database to store and report the voting data. This same approach would work on any website, even if it wasn't a MediaWiki install. The down side of this approach is that I have no idea how I would (could?) integrate the voting results into a semantic search. Can semantic data be stored stably in the SMW database without being defined in any wikitext? == Per-page voting data == I could maybe make an extension that automatically edits the current page and injects an additional vote line so all the quality votes for a given page are stored on that page. But, this seems like the most difficult option, and there would be a bunch of voting data junk in the wikitext content. Any suggestions? Thanks! --Ben -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability
Re: [SMW-devel] Looking for help with developing SMW customizations
Hi Lech, Since we're already on the subject, would you be willing to share what kind of customizations you'd like to do? It may be helpful for you, and for everyone else, to discuss your ideas here before getting heavily into code development. As noted in the SMW FAQ [1], it could be that such a feature or extension already exists, or that someone is already working on it, or that it's been discussed before and is considered infeasible, or at the very least that others will have helpful ideas about how to implement it. [1] http://semantic-mediawiki.org/wiki/FAQ#I_would_like_to_contribute_a_bug_fix.2Fnew_feature.2Fnew_extension._How_do_I_do_that.3F -Yaron On Fri, May 2, 2014 at 7:15 AM, Lech Rzedzicki xchao...@gmail.com wrote: Good day everyone. I hope this is ok with the rules of the mailing list. I am looking for an individual to help me develop customisations for SMW. The work is to be done remotely and I would prefer someone working in the GMT+/-5 hours to align with my own working hours. A good familiarity with XML/XSL and ideally also SPARQL will be a huge bonus. The company you will be working for is small and agile but has great Fortune 500 clients, mostly in publishing sector. We're scoring 9/12 on Joel Test Score (http://www.joelonsoftware.com/articles/fog43.html) - ask me for more details. Really looking forward to hearing from people!!! Lech Rzedzicki -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Looking for help with developing SMW customizations
Hi Lech, Sorry, just to clarify - when you wrote customisations for SMW, did you mean code changes to Semantic MediaWiki? Or to other extensions? Or were you talking about custom scripts and the like? There's various built-in functionality for doing some of that stuff already: the Data Transfer extension does XML imports, and SMW itself can do a JSON export, although in both cases it's a specific format that might not match what you need. -Yaron On Fri, May 2, 2014 at 9:21 AM, Lech Rzedzicki xchao...@gmail.com wrote: Thank for getting in touch about this so quickly. The project is using Semantic Media Wiki to store a data model and its documentation. Wiki pages are really like man pages - every page maps to an 'entity' in the model. Wiki is useful for people to browse the model in a readable form, but the more important factor is the ability to export to RDF and other formats, which are then used by other systems to read the model and stay in sync. If all goes well (i.e. I have enough time to finish my paper) I will be presenting more about the idea at XML London 2014 in June. The custom features vary in complexity: One of the core 'custom' features is the ability to convert XSD and XML to wiki dumps and import them to the wiki. Another is the ability to export the model in formats such as JSON, HTML+RDFa etc This is working fine, but needs a few tweak, for example ability to work with different namespaces. On the more trivial end is the need to add or edit a few more properties, templates and forms to the wiki. There also improvements needed to the development/deployment process - we are running dev/test/production instances of the wiki and we need better sync etc. Regards, Lech On 2 May 2014 14:22, Yaron Koren ya...@wikiworks.com wrote: Hi Lech, Since we're already on the subject, would you be willing to share what kind of customizations you'd like to do? It may be helpful for you, and for everyone else, to discuss your ideas here before getting heavily into code development. As noted in the SMW FAQ [1], it could be that such a feature or extension already exists, or that someone is already working on it, or that it's been discussed before and is considered infeasible, or at the very least that others will have helpful ideas about how to implement it. [1] http://semantic-mediawiki.org/wiki/FAQ#I_would_like_to_contribute_a_bug_fix.2Fnew_feature.2Fnew_extension._How_do_I_do_that.3F -Yaron On Fri, May 2, 2014 at 7:15 AM, Lech Rzedzicki xchao...@gmail.com wrote: Good day everyone. I hope this is ok with the rules of the mailing list. I am looking for an individual to help me develop customisations for SMW. The work is to be done remotely and I would prefer someone working in the GMT+/-5 hours to align with my own working hours. A good familiarity with XML/XSL and ideally also SPARQL will be a huge bonus. The company you will be working for is small and agile but has great Fortune 500 clients, mostly in publishing sector. We're scoring 9/12 on Joel Test Score (http://www.joelonsoftware.com/articles/fog43.html) - ask me for more details. Really looking forward to hearing from people!!! Lech Rzedzicki -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] Google Summer of Code: SMW projects wanted
Hi everyone, The Google Summer of Code process has already begun. SMW projects will once again be done via the Wikimedia Foundation (that is, we're not trying to apply separately, unlike in some previous years). This year the GSoC schedule is earlier than I think it's ever been - the list of accepted organizations will be announced on February 24, which is also when students will start applying for projects: https://www.google-melange.com/gsoc/events/google/gsoc2014 That's only two weeks away. So if you're thinking of trying to mentor a GSoC project, this is a good time to get involved. Here's where project ideas should go: https://www.mediawiki.org/wiki/Google_Summer_of_Code_2014#Semantic_MediaWiki I already added mine to the list. If you're looking for some inspiration, here's the set of SMW-related GSoC ideas people came up with last year: http://semantic-mediawiki.org/wiki/GSoC_2013 I think about half of these have actually been done already, which is a good sign. By the way, this applies to non-semantic functionality as well - if you want to improve, say, an ad-display extension, that would be great also, and I think the WMF would be happy to take any such projects. -Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Google Summer of Code: SMW projects wanted - Properties Edit-Tables
Hi, I agree that SMW probably couldn't be used by itself for this, and that Semantic Forms makes more sense. Thankfully, though, I don't need to create a proof of concept for this opinion, because one already exists. :) In 2011, Christoph Tempich created this demo, showing how Semantic Forms - and specifically the #autoedit function - in conjunction with some clever Javascript, can be used to create an editable table: http://smw.referata.com/wiki/Scrum Double-click on a cell within the second table, and be amazed. :) I've sent this link to the mailing list several times, by the way. as part of different threads, but for some reason it has yet to really make an impact. Still, I think Christoph's solution could be useful for a lot of cases. -Yaron -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] Allowing for disabling SMW and other Composer-installed extensions
Hi, There was a thread about a week ago on the semediawiki-user mailing list, called Howto install SMW using git?, that became a discussion about a number of things, including why there should be a way to disable extensions installed via Composer. I suggested using one or more global variables for that - like $wgDisabledExtensions. There was no real resolution to that thread, so: do any of the SMW developers on this list have any thoughts about this? I think having such a thing is crucial, whether it's done through a global variable or some other method. (Though I can't think of any other method at the moment.) -Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Allowing for disabling SMW and other Composer-installed extensions
Hi John, You're (mostly) right about the problem, but not about the solution: Composer doesn't need to be disabled to get things working - rather, there just needs to be some way to tell extensions to exit out immediately when they're included, which I'm guessing is the much easier approach. I say mostly right because, as noted in the other thread, one existing option for wiki farms is to simply have multiple installations of the code, one for each configuration (with SMW, without SMW, etc.). But, as also noted in the other thread, that very quickly becomes too unwieldy to use. -Yaron On Mon, Jan 27, 2014 at 4:03 PM, John McClure jmccl...@hypergrove.comwrote: Right I got the impression from the discussion that it's not possible to run a wikifarm that includes SMW for some sites, but not for others. Is this right? If so, it does sound as if a switch is needed to turn off composer so that wikifarm code can load extensions in the conventional way. If I missed something, please correct! Thanks/john On 1/27/2014 6:45 AM, Yaron Koren wrote: Hi, There was a thread about a week ago on the semediawiki-user mailing list, called Howto install SMW using git?, that became a discussion about a number of things, including why there should be a way to disable extensions installed via Composer. I suggested using one or more global variables for that - like $wgDisabledExtensions. There was no real resolution to that thread, so: do any of the SMW developers on this list have any thoughts about this? I think having such a thing is crucial, whether it's done through a global variable or some other method. (Though I can't think of any other method at the moment.) -Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing listSemediawiki-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] SMW no longer works with a manual LinksUpdate call?
Hi James, On Sun, Jan 19, 2014 at 11:57 PM, James HK jamesin.hongkon...@gmail.comwrote: Hi, code still responds to the LinksUpdate::doUpdate() call, but it doesn't seem to do the right thing If what you are saying is correct (that some information are missing or not doing the right thing) then no data would be stored in SMW at all ([1] is the main entry point for the Store update when receiving data from the ParserOutput object). It would also mean that our unit tests (when running on Mock) or integrations tests (when running against an actual DB) are inappropriate which seems rather odd because the data that are expected to be present and checked against are present in the Store after all. Okay... nevertheless, there are now two people who have independently observed that it's not working correctly with Approved Revs. I think the best way to prove above argument is by presenting a unit or an integration test that highlights the issue and is used as litmus test for a possible fix. I'll definitely try to do this, though I hope this is not now a requirement for every SMW-related bug report. -Yaron With regards to LinksUpdate, as for SMW 1.8/SMW 1.9 the hook LinksUpdateConstructed [1, 2] is implemented and executed to initiate a Store update. [1] http://www.mediawiki.org/wiki/Manual:Hooks/LinksUpdateConstructed [2] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/includes/hooks/LinksUpdateConstructed.php Cheers On 1/20/14, Yaron Koren ya...@wikiworks.com wrote: Hi, The Approved Revs extension no longer seems to work with Semantic MediaWiki 1.9 - someone pointed that out on the mailing list a few months ago, and I finally tested it out and confirmed the problem. Basically, when an administrator, using AR, approves some revision of a page, the AR code calls LinksUpdate::doUpdate() on that old revision of the page. This updates the category information for that page, and it is also is meant to be used by SMW and other extensions to update their own information for the page. You can see the relevant code in lines 230-236, here: http://git.wikimedia.org/blob/mediawiki%2Fextensions%2FApprovedRevs/3ff2bdc1f9b26a2d886f0d2e69b547b69c7d3748/ApprovedRevs_body.php This worked fine for SMW versions before 1.9; and in version 1.9 the SMW code still responds to the LinksUpdate::doUpdate() call, but it doesn't seem to do the right thing - it deletes the existing semantic information for the page, which is good, but it then doesn't store any new semantic information. I looked through the SMW code, and I can see the chain of functions called, but I can't really understand what it's doing, or where the problem lies. My guess is that SMW now requires something else to be called besides just LinksUpdate::doUpdate(), either before or afterwards - something that's called during a normal page save, but isn't being called by Approved Revs. That's just a guess, though. Hopefully there's an easy fix, whether it involves changing the SMW or AR code (or both). Can anyone help? I'm happy to answer any questions related to this. Thanks, Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Making SMW semver.org compliant
Hi, It sounds like your real question is, Shouldn't we have changed to 2.0 already? :) I don't know the answer to that, but I can't imagine anyone would object to increasing the version number to 2.0, 3.0 etc. if/when it makes sense to do that. (I don't think avoiding a 1.10, 1.11 etc. is by itself a good-enough reason to jump to the next number - although I may be guilty of sometimes doing that when setting version numbers for my own extensions - but anyway, ideally there are enough large-scale improvements to accompany the small ones that this sort of thing doesn't often become an issue.) On Thu, Jan 16, 2014 at 2:34 PM, Jeroen De Dauw jeroended...@gmail.comwrote: Hey, I think it would be nice if SMW was http://semver.org/ compliant. This means version numbers would look like MAJOR.MINOR.PATCH with a possible stability suffix. This is very close to what we are already doing, except that we are sticking a 1. in front of it. Having this shifted by one might not be confusing to people familiar with the SMW release cycle, though might be surprising to those who are not. How about switching to this schema for out next major release, which would then end up being 2.0? If we make this switch, the next major release seems like the best point to do this. Coincidentally one advantage to picking this release for such a change is that it makes us skip 1.10, which some users might think is smaller than 1.9.0. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Form edit with multiple templates limit
Hi Sal, Happy new year! I don't know much about this, but I did a web search and the max_input_vars php.ini setting looks relevant: http://www.php.net/manual/en/info.configuration.php#ini.max-input-vars Please let me know if changing that works for you. -Yaron On Fri, Jan 10, 2014 at 9:46 AM, Sal Quintanilla salqu...@gmail.com wrote: Hi Yaron, I had a little break for the holidays and didn’t get a chance to hit this problem until yesterday. Some experimentation is showing me that it looks like it may be the issue you suggested, PHP limiting the number of fields whose value can be passed on submission. But so far, I haven’t been able to find the setting that could help me change that limit. If you’ve got any more hints you can suggest on what I should be looking for, I’d appreciate it. Thanks. Happy New Year everyone. Sal *From:* Yaron Koren [mailto:ya...@wikiworks.com ya...@wikiworks.com] *Sent:* Tuesday, December 17, 2013 11:23 AM *To:* Sal Quintanilla *Cc:* Semantic MediaWiki developers *Subject:* Re: [SMW-devel] Form edit with multiple templates limit Hi Sal, A few variations on this question have come up on the mailing lists recently. SF itself doesn't impose any limits - but PHP and/or Javascript have their own natural limits, PHP by limiting the number of fields whose value can be passed when the form is submitted, and Javascript by slowing down the browser. If your issue is the former, it may be possible to fix it by changing the setting; with the latter, a different browser may work better. -Yaron On Tue, Dec 17, 2013 at 2:13 PM, Sal Quintanilla salqu...@gmail.com wrote: What’s the limit on the number of template instances that can be displayed in a form that uses multiple? Thanks. Sal -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [Semediawiki-user] Annotating in SMW
Hi, Bernhard - you've made a good case for having annotator functionality within MediaWiki. What you haven't really made a good case for is being able to query that annotation info using SMW, which is the relevant thing here. David - if you want to talk about the general stuff, you should probably start a separate thread for it. :) -Yaron On Tue, Dec 17, 2013 at 11:13 AM, Krabina Bernhard krab...@kdz.or.atwrote: hmm. short answer: As WikiMediaLabs is doing this: http://annotator.wmflabs.org/wiki/Lorem_ipsum it is probably going to be available in MW installations. Therfore it makes sense to have some semantification of it (and yes, general semantification is an interesting topic, the special semantic properties go in this right direction) long anwer: Sometimes I have the feeling that SMW users and devs still have the semantic encyclopedia in mind. My use cases are far more off this track. SMW has it's clear strenghts, but for some features, others put up very quick and sometimes very nice features. e.g. http://annotateit.org/ http://etherpad.org/ There are many use cases for this and of cource, then the easiest solution is to use these pieces of software. But if you look at this page https://github.com/okfn/annotator/wiki you can see a lot of plugins already available for systems like Drupal. As great as wikis are in general for many many use cases, for some things there are simpler solutions. to have these possibilities integrated in the SMW ecosystems seems a worthwile effort. concrete use case i was thinking of: a city releasing agenda items, protocols, decisions, regulacitons etc. of municipal council meetings on a wiki. the general public should not be able to edit these, but annotate them (and rate them). regards, Bernhard - Ursprüngliche Mail - Hi Yaron! I'm in favor in semantifying everything but here I'd agree with you - I don't yet see the usecase where it would be useful to have semantified inline comments. Or any comments and discussions, for that matter. - Yury Katkov, WikiVote On Tue, Dec 17, 2013 at 6:28 PM, Yaron Koren ya...@wikiworks.com wrote: Hi Bernhard, This seems like a case of the when you have a hammer, everything looks like a nail principle. :) If the extension used - whether it's Annotator or anything else - is keeping annotation information, it's presumably using one or more of its own database tables to do that. And so the most logical place to put tools to query and display that information would be in that extension itself, not via SMW. You could make the case for a Semantic Annotator extension that stores the text directly via SMW, but I don't see the benefit in that. The use cases you present are all (not surprisingly) self-contained - there's nothing like show, in a table, all annotations for pages about cars from before 1950. So I don't see much synergy in being able to query everything together. This starts to get into the larger question of whether SMW should be able to query any wiki-related data - the so-called semantification concept - but I would think if we're going to have that discussion, we should have that larger discussion, and not tie it to this particular feature. -Yaron On Tue, Dec 17, 2013 at 8:25 AM, Krabina Bernhard krab...@kdz.or.at wrote: Great, I didn't know about MashaJS. Is there a test wiki around. In the discussion there is a hint that it does not work with HeaderTabs... Which use cases do you have in mind that involved queryable inline comments? There can be reasons, where a) I want to have an overview of remarks that users made and the talk page and/or version history is too cumbersome, because you have to switch around all the time. If you want to ask users for comments on a text, a regular wiki is not very usable. annotations are great here. b) users don't want to/dare to/should not edit the text itself, but still should have to possibility to add/enhance/comment on the text It would be great to have features like: * show only annotations of user X on the page * show the text with annotations of users X and Y, but not from Z * show the users with most annotations ... regards, Bernhard - Ursprüngliche Mail - Hi Bernhard! Nice extension, reminds me of MashaJS: http://www.mediawiki.org/wiki/Extension:MashaJS Which use cases do you have in mind that involved queryable inline comments? - Yury Katkov, WikiVote On Tue, Dec 17, 2013 at 11:55 AM, Krabina Bernhard krab...@kdz.or.at wrote: Dear all, I just want to draw your attention to an interesting feature currently missing in MW/SMW: the ability to easily annotate a (wiki) document. There are lots of usecases for this and there are some first results. The interesting thing
Re: [SMW-devel] Form edit with multiple templates limit
Hi Sal, A few variations on this question have come up on the mailing lists recently. SF itself doesn't impose any limits - but PHP and/or Javascript have their own natural limits, PHP by limiting the number of fields whose value can be passed when the form is submitted, and Javascript by slowing down the browser. If your issue is the former, it may be possible to fix it by changing the setting; with the latter, a different browser may work better. -Yaron On Tue, Dec 17, 2013 at 2:13 PM, Sal Quintanilla salqu...@gmail.com wrote: What’s the limit on the number of template instances that can be displayed in a form that uses multiple? Thanks. Sal -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Offline Semantic Forms
Hi Benedikt, It could be that there's some wording confusion: by offline, did you really just mean private? It sounds like what you're talking about is people submitting data, via the internet/web, that then gets put into an external server - only one that requires a password to access; as opposed to the usual meaning of offline, meaning something that people can do locally on their computer, without any network connection. And if that's the case, maybe the easiest solution is just to have a 2nd wiki, with much more restricted viewing? -Yaron On Tue, Nov 26, 2013 at 8:28 AM, Benedikt Kämpgen benedikt.kaemp...@kit.edu wrote: Hi, Bernhard, Yury, Yaron, Neill, thanks for your answers. @Bernhardt: the Push extension is interesting, but probably will not help, here, since no information shall be pushed to the online wiki. @Yury: One important requirement is to have elaborate forms (dropdown, etc.) and a flexible form design. Not sure whether Miga could be easily extended towards this use case. @Yaron: - Would the offline form be just a copy of an online form? If so, doesn't that mean that sensitive patient data *can* get put on the wiki? Ideally, the offline form would provide the same functionality (e.g., autocompletion) than the online form. However, an offline filled-in form will never be stored on SMW but rather be put as-is on a secure file server. The question is, whether as-is actually is possible. Apparently, we are looking for some kind of JavaScript library that allows to offline modify an HTML page with forms and to save the modified HTML page. - If a physician stores data offline, can other physicians ever view it? The current plan is: After offline filling-in a form, the filled-in form will be put on a secure file server. From there it can be downloaded for viewing. - Where would the data be stored - on a single device? Ideally, the offline form could be used on various workstations. When an offline form has been filled in, it is uploaded on a single secure file server. - Would each set of offline data have its own RDF export? That is the crucial point and the reason for using SMW in the first place. The online SMW is used to define properties for patients (e.g., has BMI). An offline form shall now be used to fill in all properties for a patient. An RDF export of the offline form shall use the same properties as introduced by the online form. This way, we have a unique relationship between properties as defined by the online SMW and filled-in properties for a patient in an offline form. Ideally, an RDF export from an offline form would create the same RDF that would have been created if the form would have been filled-in in the online SMW. Maybe, the RDF export of the offline SMW could also be implemented using RDFa. - How would the RDF data be queried, if it requires FTP to access? The RDF data would be downloaded on demand from the file server and for instance loaded into a triple store for querying. @Neill: What would the Physicians use to key in the data into the form? A laptop or PC/Mac based laptop? Probably a PC with Windows. If this is the case there is nothing stopping them running a local copy of MW/SMW and then simply uploading the data to the central instance (a server somewhere I assume) using the normal MW export/import. True. We just try to avoid the additional effort of managing a local copy SMW by having offline forms that create the same RDF as an online filled-in form. I hope that makes our problem clearer. Best, Benedikt -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Error in form editing when coordinates are blank
Hi Benjamin, I, too, have experienced this problem, on a wiki that uses Semantic Maps 2.0. However, it doesn't happen on semantic-mediawiki.org, which is running Semantic Maps 3.0 alpha. Thus, I assume the bug has been fixed already (although on a version that hasn't yet been officially released). -Yaron On Mon, Nov 25, 2013 at 5:03 PM, Benjamin Pelletier bjpcalt...@gmail.comwrote: Update: I've changed the MapsLocation class in Maps/includes/Maps_Location.php to return '' rather than throwing an exception upon getLatitude, getLongitude, getAltitude, and getAddress calls when $isValid is false. This has the undesired result of showing the lat, lng position of an unspecified location at (0,0), but I don't see any other ill effects. I think this bug should be easy to reproduce locally (just create a form with a location input, then create a page with that form and leave the location blank, then edit that page with form), but here is my stack trace for reference: string(2549) #0 /var/www/ ropewiki.com/extensions/Maps/includes/Maps_Location.php(433): MapsLocation-getLatitude() #1 /var/www/ ropewiki.com/extensions/Maps/includes/manipulations/Maps_ParamLocation.php(77): MapsLocation-getJSONObject() #2 /var/www/ ropewiki.com/extensions/Validator/includes/ItemParameterManipulation.php(61): MapsParamLocation-doManipulation(Object(MapsLocation), Object(ListParameter), Array) #3 /var/www/ropewiki.com/extensions/Validator/includes/Param.php(244): ItemParameterManipulation-manipulate(Object(ListParameter), Array) #4 /var/www/ropewiki.com/extensions/Validator/includes/Validator.php(341): Param-format(Array, Array, Object(ValidatorOptions)) #5 /var/www/ropewiki.com/extensions/Validator/includes/Validator.php(281): Validator-doParamProcessing() #6 /var/www/ ropewiki.com/extensions/SemanticMaps/includes/forminputs/SM_FormInput.php(115): Validator-validateParameters() #7 /var/www/ ropewiki.com/extensions/SemanticMaps/includes/forminputs/SM_FormInputs.php(129): SMFormInput-getInputOutput('', 'Canyon[Coordina...', false, false, Array) #8 [internal function]: smfSelectFormInputHTML('', 'Canyon[Coordina...', false, false, Array) #9 /var/www/ ropewiki.com/extensions/SemanticForms/includes/SF_FormPrinter.php(1760): call_user_func_array('smfSelectFormIn...', Array) #10 /var/www/ ropewiki.com/extensions/SemanticForms/includes/SF_FormPrinter.php(1262): SFFormPrinter-formFieldHTML(Object(SFFormField), '') #11 /var/www/ ropewiki.com/extensions/SemanticForms/includes/SF_AutoeditAPI.php(822): SFFormPrinter-formHTML('includeonly?...', false, true, 119, '{{Canyon?|Regio...', 'Church Rock Can...', NULL) #12 /var/www/ ropewiki.com/extensions/SemanticForms/includes/SF_AutoeditAPI.php(116): SFAutoeditAPI-doAction() #13 /var/www/ ropewiki.com/extensions/SemanticForms/specials/SF_FormEdit.php(96): SFAutoeditAPI-execute() #14 /var/www/ ropewiki.com/extensions/SemanticForms/includes/SF_FormEditAction.php(196): SFFormEdit::printForm('Canyon', 'Church Rock Can...') #15 /var/www/ ropewiki.com/extensions/SemanticForms/includes/SF_FormEditAction.php(32): SFFormEditAction::displayForm(Object(SFFormEditAction), Object(Article)) #16 /var/www/ropewiki.com/includes/Wiki.php(439): SFFormEditAction-show() #17 /var/www/ropewiki.com/includes/Wiki.php(305): MediaWiki-performAction(Object(Article), Object(Title)) #18 /var/www/ropewiki.com/includes/Wiki.php(565): MediaWiki-performRequest() #19 /var/www/ropewiki.com/includes/Wiki.php(458): MediaWiki-main() #20 /var/www/ropewiki.com/index.php(59): MediaWiki-run() #21 {main} On Mon, Nov 25, 2013 at 10:21 AM, Benjamin Pelletier bjpcalt...@gmail.com wrote: I have a semantic form with one input that accepts coordinates, and I use Semantic Maps to let the user fill that field. I'm having a problem when that input is left blank though -- when I go to edit the page after not filling in the location, I get big red text that says Attempt to get the latitude of an invalid location and the rest of the form doesn't display. See, for instance, here: http://ropewiki.com/index.php?title=Church_Rock_Canyonaction=formedit Is there a bug for this behavior already? Thanks, Ben -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Shape the Mobile
Re: [SMW-devel] Subsection headings cripple content parsing?
Hi Ben, Wow, great! I believe this is the first real-world usage that I've seen of the new section feature in Semantic Forms. (It was added in version 2.6, about a month ago.) Unfortunately, it's accompanied by the first-ever bug report. :) Your diagnosis is correct - the subsections within that section are messing up the parsing. I guess we didn't think about the possibility of users adding subsections when we planned this feature. We'll look into this - maybe there's an easy fix. If you want to look into it yourself, I think the relevant code is around lines 1415-1450 of /includes/SF_FormPrinter.php. To answer your other question: you can make an output like that, via a hack: make the top introductory text be another field within the main template, and then have the template display that field by itself, above the infobox table. (You could also, in theory, take that same approach for all the page sections below the infobox - and some people have done that - although that's an even bigger hack, and it leads to various problems, most notably that parsing gets messed up if there's a | anywhere in the text.) -Yaron On Wed, Nov 20, 2013 at 4:43 PM, Benjamin Pelletier bjpcalt...@gmail.comwrote: Issue 1: I have a category of pages called Canyons and I've designed my Semantic Form to allow entering a bunch of simple data followed by a number of pre-determined sections. This is great for creating pages, but SF seems to choke when parsing the page content back into the pre-determined sections if subsections (=== subsection ===) are used. For example, this page works fine -- view the form to see all the content placed into the correct section boxes: http://ropewiki.com/index.php/Test_Canyon_2 But, this page is hopelessly mangled -- view the form to see content placed all over the place (and partially duplicated!): http://ropewiki.com/index.php/Test_Canyon As you can see, the Approach content is truncated at the subsection marker, the rest of the Approach content is put into Free text, the Descent section is also put into Free text (!) but also duplicated in Descent, the Exit info is appended to Descent, etc, etc Is there already a known bug for dealing with this problem? Is there anything I can do differently to get things to work properly (other than not using subsections -- that's not an acceptable solution)? Issue 2: What I'd really like to do is to not have a section header for Introduction so that the text in that box gets placed above the table of contents. Basically, I want the result to look like this: http://ropewiki.com/index.php/Eaton_Canyon Is it possible to define a section-headerless page section in a Semantic Form and also have Free text at the end (or where ever)? Where in the SF code should I go to find the routine that parses current page content into a form to see how it works? Thanks, and thanks for creating such a great product! --Ben -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Subsection headings cripple content parsing?
Hi Ben, Yes, you can use the Wikimedia Bugzilla: https://bugzilla.wikimedia.org/ Select the MediaWiki extensions product, and the SemanticForms component. On Wed, Nov 20, 2013 at 6:31 PM, Benjamin Pelletier bjpcalt...@gmail.comwrote: Awesome, sounds good. I'll implement the changes on my wiki and look forward to finding out whether the subsection fix would be easy. If it isn't, I'll see if I can dig in to changing it myself. Does SF have a bug reporting system for me to list this bug in? Thanks once more for all the responses! On Wed, Nov 20, 2013 at 3:25 PM, Yaron Koren ya...@wikiworks.com wrote: Hi Ben, Well, maybe it's not surprising that the first person to use the section tag is a new user. You have a blank canvas for your data! You should be able to tell people to use {{!}}, yes. Escaping and un-escaping pipes would be difficult, actually - there are various complications, like that the form can't know for sure what the intended variant was, and that (contrary to what I said before) sometimes pipes *are* allowed - if you have a parser function like {{#if:..., I think pipes within there are fine. (That is, they're fine for template calls - SF fails on them, I believe.) Semantic Forms' handling could definitely be improved, but I don't think it'll ever be perfect. -Yaron On Wed, Nov 20, 2013 at 5:41 PM, Benjamin Pelletier bjpcalt...@gmail.com wrote: Ah, nice, I didn't realize the section feature was that recent -- I just discovered Semantic a week or two ago and the process is just beautiful (I'm not yet finished with it). I'll let you guys take a look [at the subsection parsing thing] first since it would take me a fair amount of effort to spool up my understanding of how everything works. But if it turns out to be difficult then maybe I can give it a shot because I'd really like to have subsections work with the section feature. Thanks for the code line pointer -- I'll take a look at that for background regardless. The separate Introduction input makes sense -- that seems like a pretty reasonable hack and I think I'll adopt that approach. I should be able to instruct my users to use {{!}} instead of | in the Introduction and everything will work, right? (I already have the ! Template defined) I think I understand the benefits and drawbacks to property-izing the content and you're correct, I don't want to do that. I'm a little surprised about the | issue though -- on the one hand, I understand why that could cause problems. But on the other hand, wouldn't it be possible to sanitize and desanitize the content? Or do extensions dynamically generate wiki code rather than HTML code? (I'm not familiar with MediaWiki's architecture) Thanks again! --Ben On Wed, Nov 20, 2013 at 2:23 PM, Yaron Koren ya...@wikiworks.comwrote: Hi Ben, Wow, great! I believe this is the first real-world usage that I've seen of the new section feature in Semantic Forms. (It was added in version 2.6, about a month ago.) Unfortunately, it's accompanied by the first-ever bug report. :) Your diagnosis is correct - the subsections within that section are messing up the parsing. I guess we didn't think about the possibility of users adding subsections when we planned this feature. We'll look into this - maybe there's an easy fix. If you want to look into it yourself, I think the relevant code is around lines 1415-1450 of /includes/SF_FormPrinter.php. To answer your other question: you can make an output like that, via a hack: make the top introductory text be another field within the main template, and then have the template display that field by itself, above the infobox table. (You could also, in theory, take that same approach for all the page sections below the infobox - and some people have done that - although that's an even bigger hack, and it leads to various problems, most notably that parsing gets messed up if there's a | anywhere in the text.) -Yaron On Wed, Nov 20, 2013 at 4:43 PM, Benjamin Pelletier bjpcalt...@gmail.com wrote: Issue 1: I have a category of pages called Canyons and I've designed my Semantic Form to allow entering a bunch of simple data followed by a number of pre-determined sections. This is great for creating pages, but SF seems to choke when parsing the page content back into the pre-determined sections if subsections (=== subsection ===) are used. For example, this page works fine -- view the form to see all the content placed into the correct section boxes: http://ropewiki.com/index.php/Test_Canyon_2 But, this page is hopelessly mangled -- view the form to see content placed all over the place (and partially duplicated!): http://ropewiki.com/index.php/Test_Canyon As you can see, the Approach content is truncated at the subsection marker, the rest of the Approach content is put into Free text, the Descent section is also put into Free text (!) but also duplicated in Descent
Re: [SMW-devel] [Semediawiki-user] Videos and slides for the first SMWCon day
Hi, On Tue, Nov 19, 2013 at 6:51 AM, Yury Katkov katkov.ju...@gmail.com wrote: Hi everyone! The first day of the conference is online! You can watch the videos and slides for every one of the talks. That's great! The videos look good. I especially recommend you to watch the following talks: 1) If you'reconcerned about big amounts of data - Blue Brain talk is for you. They manage metadata about neurons and describe challenges they've faced. Besides Martin is an awesome speaker: http://youtu.be/BLcIJTXJxes 2) If you're thinking about using SMW in your business, have a look and these two: http://youtu.be/--MlUTB0g6M and http://www.youtube.com/watch?v=dP8SwTh9itI . 3) If you want to use SMW in your large company as knowledgebase you will find MITRE talk very interesting: http://youtu.be/--MlUTB0g6M Just to balance it out, I recommend you watch all the talks Yury didn't recommend. :) -Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] ajax=true - thinking about new global parameter for all Result Formats
Hi, Before we get too deep into the technical side of things, let me take a step back: Ajax, for those who don't know, is a technology where parts of the page can be modified, based on new data from the server, without needing to refresh the whole page. As far as I know, there are two advantages to having query results use Ajax: 1) It leads to faster initial page loading - especially for more involved, Javascript-based result formats, like the charting ones. 2) Results can be refreshed, manually or automatically, without reloading the page. 3) It eliminates the problem of MediaWiki caching of query results (the old why isn't that new page showing in the list? problem), because the query results aren't cached along with the rest of the page. Until now, I think I've mostly heard #1 as a reason to use Ajax in SMW query results - though, Yury, you seem to be talking mostly about reason #2. (Correct me if I'm wrong.) That seems strange to me, because I think on the vast majority of wikis, changes don't happen nearly fast enough to require any type of real-time refreshing; and certainly not for a refresh rate measured in seconds. Personally, I think reason #3 might be the strongest one, by the way. In any case, I have a question: Yury - if Ajax is possible for every result format, why both with an ajax=[true/false] parameter at all? In other words, is there ever an advantage to *not* using Ajax, given the option? -Yaron On Sun, Nov 17, 2013 at 3:48 PM, Yury Katkov katkov.ju...@gmail.com wrote: Sorry if it have looked like an attack or if I've offended you, Jeroen, I have to mind my tongue and emotions. So, what do you think about this feature from purely technical point of view? How hard is that? How much would it change the artictecture if implemented? - Yury Katkov, WikiVote On Mon, Nov 18, 2013 at 12:30 AM, Yury Katkov katkov.ju...@gmail.com wrote: That wasn't very technical :-) Not every format supports this functionality and this is also not going to happen. I'd say, that's managerial point of view AKA I decline this functionality with no explanation, like here: [1]. Come on, Jeroen, you can do better than that! Forcing them to do is makes little sense And this is problem domain/application point of view, which only reflect your experience. In some of our applications wiki supports some offline process and there it's crucial to have thi kind of 'update' button in every query including broadtable, ul, ol, filtered and maps. And yes, people there don't know anything about wikis. I can imagine similar problem in case of BPM (Alexander Gesinn) and enterprise architecture - well anywhere where you need the information to update quickly. I bet they's now using NOCACHE or struggling to explain their users why their results doesn't appear instantly. [1] http://comments.gmane.org/gmane.science.linguistics.wikipedia.technical/64153 , scroll to Tim Starling - Yury Katkov, WikiVote On Mon, Nov 18, 2013 at 12:10 AM, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, 2) could such feature be implemented in SMW core, that is: for all result formats? Or must we add these parameters to every result format separately? I'll answer this question from the technical side. Not every format supports this functionality and this is also not going to happen. (Forcing them to do is makes little sense.) Thus having a global parameter that does not work for a lot of the result formats is rather awkward. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] ajax=true - thinking about new global parameter for all Result Formats
I meant why bother instead of why both before, by the way. -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] OWA problem?
Hi John, MediaWiki is a CMS, and so is MW + SMW - first and foremost, it's a way to manage content. Also, please keep the discussion civil - even if you think someone's being uncivil to you, the best approach is to de-escalate and focus on the issues. -Yaron On Mon, Nov 11, 2013 at 1:36 PM, John McClure jmccl...@hypergrove.comwrote: Markus, your stunning words below may be confusing to more than me. MW is a CMS, SMW is /not/. Discussing 'surface syntax' of MW's wikitext, is so irrelevant to SMW's semantic annotations of that wikitext, that I don't know where to even begin... If you'd rather not discuss the options I raised, that's perfectly fine! But throwing a brick through a window, is not. /jmc On 11/10/2013 11:42 PM, Markus Krötzsch wrote: Hi John, The main point of my previous email was to explain that SMW does not implement the CWA (or OWA). The terms CWA and OWA are used to characterise knowledge representation formalisms. SMW, in contrast, is a content management software. It has neither a formal syntax nor a formal semantics. To say that SMW implements the CWA is similar to saying that SMW is green. Cheers, Markus On 10/11/13 17:26, John McClure wrote: Hi Markus - thank you for your explanation of OWA -- for more, see also [1] [2]. My question is about the default for a property's type, so let's focus prescriptively on this. In OWL, two classes are used to define a property: ObjectProperty and DatatypeProperty; in RDF, just one. OWL permits us to sidestep this issue at hand because the range is indicated by the semantics of the relevant property class. RDF properties otoh do not force any committment about the range. Because there is a single Property wiki-namespace, SMW essentially implements rdf:Property rdf:about='x', injecting rdf:type rdf:resource='owl:ObjectProperty'/ when no type annotation is provided. Of course this is not equivalent to owl:ObjectProperty rdf:about='x'/. In RDF, rdf:Property rdf:about='x' without a range means that either a resource or literal can be the target of a triple whose predicate is Property:x. So I'm thinking of four options to clarify the situation - you may have others! 1) document the CWA that SMW implements 2) establish two property namespaces, vis a vis OWL 3) permit either text or page/subobject as targets 4) refuse to create a triple similar to datatype violations Just a few ideas kicking around - thanks [1] http://www.mkbergman.com/852/ [2] http://www.cs.man.ac.uk/~drummond/presentations/OWA.pdf http://www.cs.man.ac.uk/%7Edrummond/presentations/OWA.pdf On 11/10/2013 2:33 AM, Markus Krötzsch wrote: On 10/11/13 10:43, Niklas Laxström wrote: What is OWA? John refers to the Open World Assumption. This is an informal concept used in knowledge representation to describe the assumption that statements that are not made are unknown rather than false. This is contrasted with the Closed World Assumption that is common in databases, where we assume that unspecified information is false. For example, if the ACME company has a database that contains a table for employees, and this table does not contain Bob, then one would assume that Bob is not an employee at ACME. In contrast, if an OWL ontology contains information about people (e.g., using FOAF), and the ontology does not contain Bob, one would not assume that Bob is not a person (maybe Bob just has not created a FOAF file). If we want to say that Bob is not a person in OWL, then we can do this directly by using negation; in databases, this is usually not possible and we simply assume that omitted information is negated. OWA is closely related to what we call monotonicity: the more information we enter into a system, the more informative it becomes. Databases are not monotonic in this sense: if I enter that Bob is an employee, then I add some information (that Bob is an employee) but I also remove some information (that Bob is not an employee). OWL is monotonic, but other knowledge representation languages are not. What John refers to is that SMW assumes a default type for properties (Page). Therefore, the input behaviour is not monotonic: if you specify another type later, then this will make the formerly true type Page false. However, this is not a violation of the OWA. Wikitext is just a surface syntax and not the internal knowledge model of SMW. Wikitext can never be monotonic: for example, if a page contains [[someprop::somevalue]] and you add an input character X to obtain [X[someprop::somevaue]] then SMW will no longer contain the fact. Parser functions, templates, comments, etc. will all lead to similar effects. Clearly, it makes no sense for a surface syntax to be monotonic in this sense: a meaningful notion of monotonicity cannot refer to the character level. However, the only other structure that wikitext has is
Re: [SMW-devel] SMW Seattle meetup group formed
Oh no! You should complain to them, if you haven't already - my guess is somehow they thought you were selling a product or something. -Yaron On Wed, Nov 6, 2013 at 11:58 AM, Samuel Lampa samuel.la...@gmail.comwrote: Yeah, it might be that the strong focus on local rooting, may make it less suitable for this. What's more, they just closed the SMW Stockholm group, by unspecifically referring to http://help.meetup.com/customer/portal/articles/865536 :( // Samuel On 2013-11-06 17:03, Yaron Koren wrote: Hi, I'm not aware of meetup.com http://meetup.com being used for conferences and the like. On Wed, Nov 6, 2013 at 9:47 AM, Yury Katkov katkov.ju...@gmail.commailto: katkov.ju...@gmail.com wrote: And the other question: we've thought to use Meetup.com for getting more people for the conference. Is the tool good for this, can guys from SMWCon Spring 2014 use it for outreach? - Yury Katkov, WikiVote -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu= /4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Developer at www.uppmax.uu.se www.farmbio.uu.se M: samuel.la...@it.uu.se G: samuel.la...@gmail.com S: samuellampa P: +4670-2073732 T: @smllmp B: saml.rilspace.org -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] Wikimedia Foundation accepted to Google Code-In
Hi everyone, If you don't know about Google Code-In, it's a spinoff project of the Google Summer of Code, where high school students (instead of college students) work on a bunch of small several-hour tasks (instead of one large project). The Wikimedia Foundation applied to be a mentoring organization, and they just found out today that they got in: https://www.mediawiki.org/wiki/Google_Code-In Non-WMF extensions, like SMW and the rest, are welcome as well - I asked Quim Gil, the coordinator, about it to make sure. So if anyone has any bugs they'd like fixed (reasonable ones, not large ones like making negation queries work better), this is a great opportunity for it. And if you're willing to be a mentor for such tasks, that's all the better. Google Code-In starts pretty soon - it runs from November 18 to January 6 - so if you want to get something in there, you should probably add it in pretty soon. -Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Query result rewrite
Well, yes, that's what I meant - though I guess it depends on (a) how likely this new code is to stay in SMW in its current form, (b) when it would be released as part of a stable version, and (c) how different this new interface is from the current one. But my vote would still be to teach the old thing, regardless. Just my opinion, though. -Yaron On Thu, Oct 24, 2013 at 9:36 PM, Jeroen De Dauw jeroended...@gmail.comwrote: This will exist when I give the tutorial. Are you saying that it should be in a released SMW version first? Sent from my HTC one X. -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Query result rewrite
Hi, Well, you make a strong case. And no, I think doing a result format makes a lot of sense. Good luck! -Yaron On Thu, Oct 24, 2013 at 10:17 PM, Jeroen De Dauw jeroended...@gmail.comwrote: Hey, The point of this workshop is not to teach people SMW interfaces. The amount of ground that can be covered in a one hour workshop aimed at beginners is rather small. So however this is done, people will still not know nearly all interfaces. So even if it was the case that this was likely to change, which it is not, I'd not see it make much of a difference. People still get to learn the workflow and they still get to learn how to find things out while creating an SMW extension, which is the whole point. If you have a suggestion for something that is not a result format that could be created as part of the workshop, and that interfaces with code that does not prevent writing tests for the new code, then I'd be happy to hear about it. There is the Ask library, though that is likely to abstract for much of the audience. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Specific questions | Re: Current status and future plans of (REST) API:s and import in SMW?
Hi Samuel, Sorry that I'm not answering any of your questions, but I wanted to clarify something. My understanding of RDFIO is as follows: it takes in triples that might look like: Joe Average foaf:phone 123-4567 For such a triple, it would then find the page on the wiki called Joe Average, and if it doesn't exist, create it; and add something like the following to the page: [[Phone::123-4567]] It would then also create the page Property:Phone on the wiki, and add to it something like: [[Has type::Telephone number]] (...or String, Text, etc.) [[Equivalent URI::http://xmlns.com/foaf/0.1/phone]] The latter seems totally fine to me. It's the former, the actual placement of data on the page, that seems like it might be a problem. As I'm sure you know, SMW data these days is usually stored via templates. Templates have a lot of advantages to them, even if you're not using forms: they enforce a consistent data structure and display, they make it easier to modify the semantic back-end, and they make editing easier, again whether or not you use forms. So I would think that, ideally, any import system should create or modify template calls, instead of adding hard-coded SMW tags. You might argue that it doesn't really matter because users aren't supposed to be editing these calls anyway - that SMW is just being used as a storage mechanism for RDF data that's generated and maintained elsewhere. If that's true, though, then maybe the whole concept of using SMW is an unnecessary hack? I know that SMW offers a lot of advantages in terms of visualization, but perhaps the real effort should be spent on getting visualization of arbitrary RDF data improved? There are various tools that could potentially be used for the job - Spark, Exhibit, Miga (sorry for the plug), and who knows what else. This probably deserves a separate thread; but using SMW as a repository for external RDF seems like both a hack and contrary to the spirit of RDF - which is all about distributed queries. SPARQL + result formats, in whatever form that takes, could be a big deal. If the goal is rather a one-time import - and for the wiki's users to edit the data from that point on - then again, I think template calls are the way to go, if that's possible. That might require a retooling of at least the import interface, though. Any thoughts? Am I missing something? -Yaron On Tue, Oct 22, 2013 at 9:18 AM, Samuel Lampa samuel.la...@gmail.comwrote: I realize my post was a kind of fussy, so here are a few specific questions instead: == Question 1: Current status for import in SMW == Is there any ongoing work to improve the import functionality in SMW? == Question 2: Interest in developing import in SMW == Is there any interest or even plans to improve the import functionality in SMW? == Question 3: Interest in rewrite / update of SMWWriter == More specifically, is there any interest in rewiving / rewriting / updating SMWWriter [1], or create something equivalent: A generic fact-editing interface, as an extension to the MediaWiki API? Comment 1: Note that SMWWriter (and later RDFIO) provides fact editing via *update of wiki articles*, not by directly inserting into a triple store. This is a big distinction, as most other SMW import tools I have seen take the second approach. The first approach though, of importinng *via wiki article updates*, has the benefit that it is totally independent of what triple store is using, and is of course crucial if one wants to have the wiki articles and the triplestore, in sync. Comment 2: It would be nice to have one, well supported, such functionality, which I could build upon from RDFIo, and other RDF / SPARQL tools that needs import functionality, could use as well. == Comments on all the questions == The background to these questions is that I'm thinking about the future of import in SMW and would be happy if the core import functionality could be maintained for a foreseable future, independent on development of 3rd-party extensions such as RDFIO. I'm happy to help in that direction, but to make this become a trusted high-quality part of the Semantic Bundle for example, I'm afraid, would require the skills of someone with more programming experience and in-depth knowledge of SMW internals. Thus, I'm polling whether someone is interested in taking on such a project, alone or in collaboration? Best Regards // Samuel [1] http://semantic-mediawiki.org/wiki/Help:SMWWriter On 2013-10-21 15:23, Samuel Lampa wrote: Hi all, What is the current status of (REST) APIs and import functionality in SMW? As some of you might have noticed, I have been working a bit lately on trying to finish the RDFIO extension to a workable state, efter many years. At the same time, haing gone, over the last couple of years, to a very green coder-wannabe, to having at least some year of working coding experience, I start to get some perspective of what was the
Re: [SMW-devel] Gerrit #84744: Disable type enforcement for properties with names equal to type names
Hi Vitaliy, I'm not a core SMW developer, so there's not much I can do on this issue; but maybe there are some SMW developers reading this, who can at least express an opinion on the subject. Anyone? On Tue, Oct 1, 2013 at 3:37 PM, vita...@yourcmc.ru wrote: I agree with you here. I don't think backwards compatibility is a compelling reason to keep the property-name-dictates-type feature. I don't believe there are that many wikis that have such a property defined without an associated type - and conversely, we know of a few wikis where this feature has caused problems, that have, for example, a property named Telephone number of type String or Text. I think it makes a lot of sense to just toss this feature out entirely - it will cause some short-term pain for a few admins, but in the long term it will simplify both the code base and the usage of SMW. Thanks Yaron! So, what do you think should be done next? :) -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Gerrit #84744: Disable type enforcement for properties with names equal to type names
Hi Vitaliy, I agree with you here. I don't think backwards compatibility is a compelling reason to keep the property-name-dictates-type feature. I don't believe there are that many wikis that have such a property defined without an associated type - and conversely, we know of a few wikis where this feature has caused problems, that have, for example, a property named Telephone number of type String or Text. I think it makes a lot of sense to just toss this feature out entirely - it will cause some short-term pain for a few admins, but in the long term it will simplify both the code base and the usage of SMW. -Yaron On Mon, Sep 23, 2013 at 10:14 AM, vita...@yourcmc.ru wrote: Hi! It seems the discussion in https://gerrit.wikimedia.org/r/#/c/84744/ is slowed down, so maybe we'll discuss it here? The full history is that I've recently discovered a strange SMW behavior - type-named properties with enforced type. I.e. property named email ALWAYS has email type, and you cannot override it. Markus said it was done for some sort of backwards compatibility (details are in gerrit), and I think it's an unevident behaviour, so I still think it should be disabled... To not break things with disabling this feature I suggest creating a maintenance script (run as part of update.php) which will look for usage of type-named properties and create them with [[has type::name]] if they're really used. What do you (SMW developers), and this mailing list subscribers in general, think about it? -- With best regards, Vitaliy Filippov -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] SFFormLinker::setBrokenLink is doing what?
Hi, It's been quite a while since I looked into the red-link handling, and I don't remember what the difference is between the queries (they both call SMW code to do the actual querying), but from what I recall it was a pretty significant performance difference. It would be easy to add a setting to disable red-link handling altogether, but I don't recall anyone ever requesting such a thing - it's a pretty useful feature. On Thu, Sep 19, 2013 at 2:16 PM, Jeroen De Dauw jeroended...@gmail.comwrote: Hey, There's a setting you can use, $ sfgRedLinksCheckOnlyLocalProps, that, if you set it to true, makes it so that setBrokenLink() checks only the properties defined on this page, instead of all properties across the wiki. It makes the whole thing less effective, but it should reduce the running time considerably. So what is the difference in queries that get executed? I'm not sure what is happening exactly, though suspect that even if you do only local props, a decent chunk of the cost is still there. If that is the case, being able to fully disable it might be quite useful for certain people. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [Semediawiki-user] Error with SIO and SF
Hi Bernhard, You've uncovered a bug in SF (it's not related at all to SIO) - the presence of -Adressen.Bezirk (specifically, the first -) is messing up the process of associating template fields with properties. There's an easy fix, although unfortunately for some reason there's an issue right now on my server that's preventing me from checking in code. But you can fix it in your own code by adding the following lines to the file /includes/SF_TemplateField.php, at the top of the function setTypeAndPossibleValues(): if ( strpos( $this-mSemanticProperty, '-' ) === 0 ) { return; } -Yaron On Thu, Sep 12, 2013 at 6:16 AM, Krabina Bernhard krab...@kdz.or.at wrote: Hi, I think I have encoutered a bug using Query Forms of SF in combinatio with SIO: Here is a working query: http://standards.kdz.eu/index.php?title=Test:Abfrage_Bauwerk The same query throws an exception when used in a Query Form: http://standards.kdz.eu/index.php?title=Spezial:Abfrage_ausf%C3%BChren/Abfrage_Bauwerk try to select Gebäude. If you also enter 9 in Bezirk the following exception is thrown: Illegal property key -Adressen.Bezirk. Backtrace: #0 /home/kdz/standards/extensions/SemanticMediaWiki/includes/dataitems/SMW_DI_Property.php(272): SMWDIProperty-__construct('-Adressen.Bezir...', false) #1 /home/kdz/standards/extensions/SemanticForms/includes/SF_TemplateField.php(75): SMWDIProperty::newFromUserLabel('-Adressen.Bezir...') #2 /home/kdz/standards/extensions/SemanticForms/includes/SF_TemplateField.php(105): SFTemplateField-setTypeAndPossibleValues() #3 /home/kdz/standards/extensions/SemanticForms/includes/SF_TemplateField.php(28): SFTemplateField-setSemanticProperty('-Adressen.Bezir...') #4 /home/kdz/standards/extensions/SemanticForms/includes/SF_TemplateInForm.php(22): SFTemplateField::create('Bezirk', 'Bezirk', '-Adressen.Bezir...', false) #5 /home/kdz/standards/extensions/SemanticForms/includes/SF_TemplateInForm.php(74): SFTemplateInForm-handlePropertySettingInTemplate('Bezirk', '-Adressen.Bezir...', false, Array, '??{{#ask: {{#if...') #6 /home/kdz/standards/extensions/SemanticForms/includes/SF_TemplateInForm.php(136): SFTemplateInForm-getAllFields() #7 /home/kdz/standards/extensions/SemanticForms/includes/SF_FormPrinter.php(518): SFTemplateInForm::create('Abfrage Bauwerk') #8 /home/kdz/standards/extensions/SemanticForms/specials/SF_RunQuery.php(79): SFFormPrinter-formHTML('noinclude??{{...', true, false, 346, NULL, NULL, NULL, true, false) #9 /home/kdz/standards/extensions/SemanticForms/specials/SF_RunQuery.php(30): SFRunQuery-printPage('Abfrage_Bauwerk', false) #10 /home/kdz/standards/includes/SpecialPage.php(611): SFRunQuery-execute('Abfrage_Bauwerk') #11 /home/kdz/standards/includes/SpecialPageFactory.php(494): SpecialPage-run('Abfrage_Bauwerk') #12 /home/kdz/standards/includes/Wiki.php(290): SpecialPageFactory::executePath(Object(Title), Object(RequestContext)) #13 /home/kdz/standards/includes/Wiki.php(536): MediaWiki-performRequest() #14 /home/kdz/standards/includes/Wiki.php(446): MediaWiki-main() #15 /home/kdz/standards/index.php(59): MediaWiki-run() #16 {main} Here ist the template: http://standards.kdz.eu/index.php?title=Vorlage:Abfrage_Bauwerk and the form: http://standards.kdz.eu/index.php?title=Formular:Abfrage_Bauwer regards, Bernhard -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ Semediawiki-user mailing list semediawiki-u...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-user -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [Semediawiki-user] Status of faceted search for SMW
Hi Yury, There are, of course, a number of existing faceted search solutions that don't require any patches: - The Semantic Drilldown extension - The Special:RunQuery page of Semantic Forms - The filtered result format in Semantic Result Formats (I'm assuming it still works, though I don't know) - The SolrStore extension (again, I assume it works) - Miga (http://migadv.com) - not a MediaWiki extension, but can be used to provide a faceted search interface for SMW data My guess is that you have some specific interface requirement, like that it should look like Exhibit, but I don't know. -Yaron On Fri, Aug 16, 2013 at 2:11 AM, Yury Katkov katkov.ju...@gmail.com wrote: Hi guys! Year after year I listen and read about various teams working on their implementations of filtered/faceted search for Semantic MediaWiki. Does anyone has the results that don't require patching the core? Something like that maybe? http://i.imgur.com/pwNmMiq.png Cheers! - Yury Katkov, WikiVote -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Semediawiki-user mailing list semediawiki-u...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-user -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC: SMWPageSchemas in SMW core (1.9)
Hi, I didn't know whether you were serious about splitting off the SMW PS class into its own extension, but clearly you are - and you might want other functionality split off as well, like maybe an #info tag extension. I don't know whether it's worth having a full discussion about the philosophy of extension size on this list - there was a long discussion about this topic on the wikitech-l mailing list last month that covered the main points, which anyone can see here: http://www.gossamer-threads.com/lists/wiki/wikitech/375342 This is a big topic, but I'll just say that the view of MediaWiki extensions as libraries or packages is, in my opinion, not an accurate description. If there were a true package management system for MediaWiki, that everyone could use easily, it might be a different story, but at the moment there isn't. So many people end up maintaining many different versions of MediaWiki and many different combinations of extensions, each with their own versions; and the more extensions there are, the more work it is for admins and the more things that can go wrong - and by extension, the more work it is for developers who have to document all the installation steps, detail all the version compatibility issues, and help with debugging every time something goes wrong. But, back to this specific issue: what exactly is the liability of having this PS SMW class/file contained in SMW? You and James have both said that it would cause problems, but I don't see how. Even in the worst case, where the code in the class is awful and doesn't work at all, as long as it doesn't affect the normal running of SMW it shouldn't be an issue for SMW developers. If you see a bug report or email relating to the SMW PS code not working, you can either ignore it or assign it to whoever is maintaining Page Schemas (at the moment, sending it to either me or Yury would be fine). Is it really an issue that one or more classes in SMW are not covered by unit tests, other than an aesthetic one? -Yaron On Sat, Aug 10, 2013 at 2:25 AM, Jeroen De Dauw jeroended...@gmail.comwrote: Hey, I can think of a number of things that SMW does, unrelated to its core goals: SMW core could indeed be more lean. Now, maybe the right solution is to split off all of this extra stuff into one or more other extensions, as was done with DataValues (and perhaps with Diff and the rest - I don't know if those started out as SMW code). Diff is not related to SMW in any way. DataValues is based on SMW code though not yet used directly by SMW. That is something planned though. Personally, though, I think the better solution is to just view SMW as an extension that does a lot of things, in the back-end and interface, related to the storage of semantic data. It is important to differentiate between the developer and the user views on this. From a development perspective it makes a lot of sense to have these things nicely kept separate. From a user perspective certain combinations of packages tend to be desired. This is why software tends to have a build process, so the selection of functionality needed by the user can be put into an easy to use bundle that appears to be one piece of software to the user. And since different users have different needs, you'd typically have a few variants of this. For instance SMW core with just the core stuff, SMW plus forms and related stuff, and ALL of the SMW things. Right now we are not doing an as good job at providing such things as we could. SB is a step in the right direction, though still far from what we could have. From a dev perspective it is important to keep district things separate, to avoid not needed dependencies creeping in, and to reduce maintenance costs. Since we have not all that much manpower for maintenance, we should be very careful about this. Some factors that are relevant in determining if something should go into SMW core are size and code quality. In case of the Admin Links hook, which is just a few lines of simple code, there is not all that much reason to move it out. There is more PS code though, and it is more complex. Plus it has design issues which combined with the lack of tests make it a liability. In the case of the PS code, I'm not convinced that having a PSSMW extension would be to much of an issue even without improving our current build and publishing process. After all, there are many much smaller MW extensions out there. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes.
Re: [SMW-devel] RFC: SMWPageSchemas in SMW core (1.9)
Wow... I don't know if there's ever been such quick consensus on a topic on this list. Evidently that Page Schemas class has been bugging people for a long time. :) Yury wrote: I remember Yaron have explained that it's a legacy remained from some kind of global plan of making PageSchemas the central framework for managing all kinds of extensions. I don't recall ever having said that... not that I understand what it means. I'm not even sure what a global plan is. :) The idea with Page Schemas is that it's a framework for defining a data structure and generating the necessary pages based on that structure - but the specifics of the structure and the page-creation are defined by the set of extensions installed. Now, as was pointed out, all this logic could go into Page Schemas itself, but I think it's a nicer solution to have each extension provide its own logic: - Whenever an extension's data structure details change, it can take care of modifying its Page Schemas code on its own, ensuring that Page Schemas will always (up to a point) work correctly with the current installed version of that extension. - Each extension provides its own i18n messages for the extension-specific text it provides to Page Schemas - I think that's a much nicer solution than having Page Schemas hold a ton of messages that actually relate to the workings of other extensions. - New extensions that want to add their data structures into Page Schemas can do that, and further modify their code, without any coordination with me or whoever is maintaining the PS code at the time. Now, any approach to this kind of thing will have code-compatibility issues, so I shouldn't say that in this current approach the extensions will always work correctly together. If the Page Schemas API changes in any way, then of course the extensions' code will all have to change, which is a downside. But on the other hand, I think changes to the data structure are likely to happen on a much more frequent basis than changes to the Page Schemas API. My planned changes to the Semantic Drilldown extension, for instance, will require removing some fields from the Semantic Drilldown Page Schemas interface. This is not unique to Page Schemas, by the way - my Admin Links extension does the same thing, and SMW (along with other extensions) also has code specific to Admin Links. Or maybe I shouldn't have said that. :) And there are potentially other extensions that could use the same setup - like an extension that let you configure LocalSettings settings from the web interface. I think the Configure extension, which does that but holds all its settings in one place, would have been a lot stronger if it had used a hook-based system to let each extension define its important settings itself. -Yaron On Thu, Aug 8, 2013 at 8:24 AM, Markus Krötzsch mar...@semantic-mediawiki.org wrote: On 08/08/13 13:18, Jeroen De Dauw wrote: Hey, I concur with James on the points he made. The approach taken would make more sense if SMW was a plug in to PS, as this is what the code makes it out to be. I'd rather see the code be part of PS, and have it only be registered there is SMW is loaded. +1 Markus Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes.
Re: [SMW-devel] RFC: SMWPageSchemas in SMW core (1.9)
Hi, On Thu, Aug 8, 2013 at 9:48 AM, Jeroen De Dauw jeroended...@gmail.comwrote: Hey, Wow... I don't know if there's ever been such quick consensus on a topic on this list. Yes, you have won of badge of some sorts :) I'm not even sure what a global plan is. :) Ah, of course you would deny your secret plans to take over the world, and then install SMW everywhere. Well, it's true that I'm constructing a giant laser beam, but it's for, uh, research purposes only. :) But on the other hand, I think changes to the data structure are likely to happen on a much more frequent basis than changes to the Page Schemas API. This might be true. However if you look at what is actually happening, nothing of this nature has changed since the introduction of the class. That's true, although things do change - as I noted, there's a plan for the Semantic Drilldown structure to change sometime in the near future. And the SMW setup could potentially change as well. A big part of the reason why there haven't been any changes in the SMW class is that SMW doesn't do any page-generation itself - Semantic Forms takes care of some of the things that perhaps ideally SMW itself should hold, like the CreateProperty and CreateTemplate special pages. (That's a subject for another thread, though - I don't mean to derail this one.) So it's the SF PS code that changes if there's a change to the SMW data structure setup, like the recent removal of the String property. But if the helper forms for creating properties and/or SMW-based templates were to ever move to SMW, SMW's Page Schemas class would most likely start needing updates on any data structure change. Which I think is as it should be. From an SMW maintenance perspective, it is not nice to have this code in there. And having this semi dependency on PS makes things more fuzzy for both users and devs. I don't actually see it as confusing or difficult, personally - I think it's a nice, modular approach to creating an interface that involves the behavior of a bunch of extensions. As I noted, Admin Links takes the same approach, and I don't think that one has caused any confusion (though perhaps I shouldn't keep mentioning it :) ). A third option is to have a PSSMW extension that depends on both SMW and PS, and contains the code in question. This of course comes with its own set of tradeoffs. Presumably one such extension can be made to hold PS all code for SMW and SMW extensions. Oh... adding another extension sounds like a worst-case scenario. Especially if the goal is to prevent user confusion... -Yaron Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC: SMWPageSchemas in SMW core (1.9)
Hi, Well, I think you've reached the crux of the issue, which is the question of what exactly SMW should be in charge of doing and what it shouldn't. If you view SMW as essentially a library that provides data storage, data access, or querying for MediaWiki - sort of a MySQL for MediaWiki - then indeed having the Page Schemas dependency is not appropriate. However, I think it makes more sense to view SMW as an extension that provides a lot of support related to the storage and querying of data. I can think of a number of things that SMW does, unrelated to its core goals: - Helper pages like Special:Properties (though that arguably is part of core functionality) - RDF export of data - The Powered by SMW button on the bottom of pages - The #info tooltip function - Adding to the Admin Links page (maybe I really should stop mentioning this one) - Defining various things related to Semantic Forms - the Form: namespace, the type used by special properties like Has default form. In addition, I think it could make some sense for SMW in the future to incorporate any of the following features currently in Semantic Forms: Special:CreateProperty, Special:CreateTemplate, #arraymap and #arraymaptemplate. None of those are of course necessary for SMW to function. Now, maybe the right solution is to split off all of this extra stuff into one or more other extensions, as was done with DataValues (and perhaps with Diff and the rest - I don't know if those started out as SMW code). Personally, though, I think the better solution is to just view SMW as an extension that does a lot of things, in the back-end and interface, related to the storage of semantic data. It's true that the SMW Page Schemas class doesn't actually contain that much SMW-specific code (though certainly some of it is SMW-specific) - but, as I noted, that's really just an accident of history, based on the fact that creation of property pages and the like is done by Semantic Forms. If that ever changes, the code in the SMW PS class will look a lot more SMW-heavy. As for testing the code - it wasn't quite clear from the way you worded it, but I assume you're saying that this class is not testable, not that the presence of this class makes all of SMW not testable. Assuming it's the former, yes, it would probably require integration testing and not unit testing, but I'm sure it's all doable in theory. -Yaron On Thu, Aug 8, 2013 at 11:47 AM, James HK jamesin.hongkon...@gmail.comwrote: Hi Yaron, If we look from a point where we see SMW core being assigned to tasks like data storage, data access, or querying then the implementation of SMWPageSchemas feels a bit sidetracked to the point where: For example having code like [1] where $psTemplateField is some kind of an object but without specific type hinting it could be anything and its dependency is more than vague (from a SMW core point of you it is non-existent because any operation that happen an behalf of this object is unknown to SMW core). Which part of SMWPageSchemas is so specific to SMW that it requires SMW itself. As far as I understand SMWPageSchemas is mostly doing string/array manipulations like [2] of some sort but when it comes to property/value access it relies on [3] or [4], meaning that data access is not the issue. SMWPageSchemas acts as a formatter of raw values that PageSchemas can present to a consumer. SMW core doesn't (and it shouldn't) know anything about formatting rules that are required by PageSchemas (of course now it does because of SMWPageSchemas). Nothing in the code points to a truly SMW core specific (data storage, data access, or query related) task that could not be done by a generic object formatter, so why does SMW core has to implement something like [5] when the only consumer of the code is the PageSchemas extension, making SMW core depending on PageSchemas for this specific class (and make it actual not testable because of the forced dependency). [1] $prop_array = $psTemplateField-getObject('semanticmediawiki_Property'); if ( empty( $prop_array ) ) { continue; } [2] $typeTag = [[$hasTypeLabel::$propertyType]]; $text = wfMessage( 'smw-createproperty-isproperty', $typeTag )-inContentLanguage()-text(); [3] PageSchemas::getValueFromObject( $prop_array, 'name' ); [4] PageSchemas::getValueFromObject( $prop_array, 'Type' ); $allowedValues = PageSchemas::getValueFromObject( $prop_array, 'allowed_values' ); [5] $html_text .= Type: . Xml::tags( 'select', $propertyDropdownAttrs, $select_body ) . /p\n; Cheers On 8/8/13, Yaron Koren ya...@wikiworks.com wrote: Hi, On Thu, Aug 8, 2013 at 9:48 AM, Jeroen De Dauw jeroended...@gmail.comwrote: Hey, Wow... I don't know if there's ever been such quick consensus on a topic on this list. Yes, you have won of badge of some sorts :) I'm not even sure what a global plan is. :) Ah, of course you would deny your secret plans to take over
Re: [SMW-devel] SMW and the HotCat gadget
Hi Ryan, What do you mean by SMW friendly? -Yaron On Jun 28, 2013 1:07 PM, Ryan Glasnapp ryan.glasn...@gmail.com wrote: Is anyone aware of a SMW friendly version of the HotCat gadget? Thanks! --Ryan -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Making subobjects correctly ordered
Hi, Okay - so there's at least some consensus for keeping the subobject hash as it is. That means that, for subobjects to be sortable by entry order, I think there would have to be a separate special property, called Has index or Has number or something, that would store the index of each subobject on the page. However, there are a few weaknesses to that approach that I can think of: - Creating a new special property takes some development work - including, possibly, creating a new database table? - Subobjects won't be sorted automatically; whoever creates each query will have to remember to add sort=Has index to the query. - Because of the way sort= works (it removes all items that don't have that property), it will cause some confusion for wikis starting to use the new code: subobjects that don't have Has index set yet will simply not show up in sorted queries. For these reasons, I'm leaning heavily toward just changing Semantic Internal Objects to use hashes like #001, #002, etc. again, like it used to do. That way, users will have a choice of naming schemes. And it somewhat fits in with the different philosophies of SMW/subobjects vs. SIO: in SMW, such objects can have their own name and identity, while in SIO, they're really only attributes of the page on which they're defined. -Yaron On Fri, Jun 21, 2013 at 4:31 AM, Stephan Gambke s7ep...@gmail.com wrote: On 20 June 2013 20:32, Yaron Koren ya...@wikiworks.com wrote: As for whether storing the index, whether it's part of the subobject name or in a Has index property, changes the data model - I don't think it does. I think that could work as long as you do not change the identity of the subobject. I.e. these additional properties should not be stored in the hash directly nor used to produce the hash. You can simply ignore the index value; I would just think of it as additional data that can either be used or not. If you didn't like my Modification date example, how about this: the subobject hash itself is some additional, SMW-only data that gets added to each row, but that doesn't affect the data model either. -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] Making subobjects correctly ordered
Hi, The other thread about #subobject and #set_internal reminded me that I've been meaning to ask about this: Currently #subobject names all the subobjects it creates in the form Page name#hash (I referred to the hash previously, incorrectly, as a random string). There's a problem with this approach, though, which is that the subobject names don't preserve the order in which they were created. Let's say you have a bunch of #subobject calls in a page (ideally within multiple-instance templates, though it could be done in any way), representing something that has a natural order, like a set of sub-tasks in a project, and you want to display all those sub-tasks in some table on another page. An #ask query on another page won't display them in the same order in which they were entered - by default, it'll go by the subobject name, which will display them in a random (or random-seeming) order. You could of course require users to enter a number for each entry, and then sort on that in the queries; or you could use an extension like NumerAlpha [1] (I haven't used it, so I don't know how well it actually works), but I think it would be nice for this to just work out of the box - that, without any additional work, subobjects get displayed in queries in the same order in which they were entered. If having the unique hash element is important, I can think of a solution that would preserve that, while also making the ordering correct. Right now subobject names look like: Page name#_4bd1f1b74a76de5322dd74956a71f089 Page name#_03163dfd1d2502668b00c1f521688984 You could just prepend an index number at the beginning, so they would instead look like: Page name#001_4bd1f1b74a76de5322dd74956a71f089 Page name#002_03163dfd1d2502668b00c1f521688984 Without getting into the details of technical implementation - does that sound like a reasonable change? [1] https://www.mediawiki.org/wiki/Extension:NumerAlpha -Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Making subobjects correctly ordered
Hi Alexey, Yes, that's a good point - I actually thought about an approach like that, but forgot to include it in the email. A property called Sort (a name like Has index might be a little clearer) would solve this problem - and it would be a more semantic solution. On the other hand, it would add to the proliferation of special properties (for what that's worth), and it would mean a little more work for administrators to get queries of subobjects ordered correctly. I still think my original proposed solution would work fine, though I confess I don't quite understand how the subobject hashing works. Are people supposed to be able to directly link to or reference a subobject, using the hash? I don't see how that could work, given that everything about a subobject could change from one page save to the next - its order, its properties, etc. I don't see how the system could keep consistency of subobject naming. -Yaron On Thu, Jun 20, 2013 at 10:54 AM, Alexey Klimovich god.vedm...@gmail.comwrote: Hi, Yaron! I think subobjects sorting is good task, but i suggest not to use subobjects name for this because of big problem with that: imagine we have 3 subobjects on page: Page name#001_4bd1f1b74a76de5322dd74956a71f089 Page name#002_03163dfd1d2502668b00c1f521688984 Page name#003_02dwa3j349j8d3jds3843234jd8349490 now, we edit page, delete subobject 002. What should happen? Should other subobjects be renamed to keep sorting? What if they already linked from other pages/queries? I think better way is to automaticaly attach some semantic property (Sort for example) to every subobject on page. This property should contain subobjects number on page. -- View this message in context: http://wikimedia.7.x6.nabble.com/Making-subobjects-correctly-ordered-tp5007553p5007558.html Sent from the Semantic Mediawiki - Development mailing list archive at Nabble.com. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Making subobjects correctly ordered
Hi, Alexey - as Stephan notes, the hash is based on the set of parameters to #subobject, which means that if you even change one value the hash will (I think) change. Which means that linking/referencing a specific subobject based on its hash is not that good of a long-term strategy, I don't think. Though I find it strange to do that kind of thing in the first place, anyway - if something is going to be linked to/discussed directly, as opposed to just aggregated, I would think it should have a true name. But I don't know what the data you're talking about is. Jamie - your usage sounds interesting, but I think not relevant to this discussion, since you don't need to sort based on entry order. Stephan - you make some good points. As far as displaying the number/index in queries - that sounds interesting, though even a separate Has index property might not necessarily be ideal for that. If you have two or more different kinds of #subobject calls on a page, it might not work out nicely. For instance, a recipe page might have subobjects for ingredients, and then subobjects for instructions. In that case, the ingredients might have Has index values of 1-10, and then the instructions might have Has index values of 11-15. (That's how numbering used to work in SIO.) So displaying this property might just look weird. Your second point is that the hash system lets SMW only display unique subobjects. Which is true, but (a) in my experience that's not a major issue, and (b) actually, sometimes you really do want to store duplicate data. What if you have a page of test scores, and you use #subobject to store each student's name and their score, and two students happen to have the same name and the same score? (Let's say that there aren't wiki pages for each student, which would force you to disambiguate.) Duplicate data might not be an error - it might be valid data. You seem to also make the point that, because it hasn't been entered by a user, the index/number isn't truly a part of the data model, and shouldn't be stored at all. Assuming you are in fact making that point, it's a reasonable opinion, but I disagree, for two reasons: (1) the order of elements is something that users can control, and thus, it is actually implicitly part of the data model, and (2) SMW already stores a bunch of stuff that's even less a part of the data model: the Modification date property, etc. You could say that two wrongs don't make a right (to use an expression), but at the very least, this wouldn't be breaking anything that's not already broken. Again, though, I'm not sure if that's what you were getting at. -Yaron On Thu, Jun 20, 2013 at 12:37 PM, Stephan Gambke s7ep...@gmail.com wrote: Hi Yaron, I do not think that your approach will work. At a first glance it seems to be an easy way out to provide sorting. But from a software engineering point of view it loads the identifier with information that just does not belong there. From a practical point of view it falls short if anybody wants to query that number. And finally from a semantic point of view it inseparably mixes two statements (the original one and the one about the sequence number) that the originator usually does not want to be mixed. This last problem btw is also the key to your question about the determination of the hash key. To state the same thing twice is just that: A duplicate statement. As opposed to two statements. To my best knowledge SMW will not store such a statement twice. Instead it will generate the hash key based on the property and value and if that hash already exists, then the statement it represents is considered already known and the second occurrence will be dropped and not appear in any query results. I am not sure if this is also true for subjects, but it really should be. So, long story short: If your data model for project management does not explicitly contain the sequence number for the activities, then your model is incomplete, not SMW. In fact, should two activities be exactly the same, you will probably lose one of them. Cheers, Stephan On Jun 20, 2013 5:30 PM, Yaron Koren ya...@wikiworks.com wrote: Hi Alexey, Yes, that's a good point - I actually thought about an approach like that, but forgot to include it in the email. A property called Sort (a name like Has index might be a little clearer) would solve this problem - and it would be a more semantic solution. On the other hand, it would add to the proliferation of special properties (for what that's worth), and it would mean a little more work for administrators to get queries of subobjects ordered correctly. I still think my original proposed solution would work fine, though I confess I don't quite understand how the subobject hashing works. Are people supposed to be able to directly link to or reference a subobject, using the hash? I don't see how that could work, given that everything about a subobject could change from one page save
Re: [SMW-devel] Making subobjects correctly ordered
Hi Stephan, For the duplicate data thing: you're right that duplicate data is never a good idea; I was wrong about that. Still, in practical terms I really don't think it matters whether the duplicate data gets stored or not. Duplicate data just doesn't happen very much, if at all; and even when it happens, that's an error in data entry: SMW doesn't have any obligation to fix such errors. (I think all of this is somewhat incidental, actually, because however the index gets stored, there should always be a way to prevent duplicates using the hash.) As for whether storing the index, whether it's part of the subobject name or in a Has index property, changes the data model - I don't think it does. You can simply ignore the index value; I would just think of it as additional data that can either be used or not. If you didn't like my Modification date example, how about this: the subobject hash itself is some additional, SMW-only data that gets added to each row, but that doesn't affect the data model either. -Yaron On Thu, Jun 20, 2013 at 2:04 PM, Stephan Gambke s7ep...@gmail.com wrote: Hi Yaron, I did not propose a general 'has index' property. In fact, I would strongly advise against it. Your recipe example is a good one for a case where an index does not make sense and implying one would be wrong. For the students example: If your data model identifies students by their name alone, then again the data model is insufficient, not SMW. Basically your statement is 'John has a score of 2'. If you repeat that statement, then a natural person will tell you that you already said that. SMW will drop the second statement. If you actually want both of these statements stored you better think of a way to disambiguate. On the point of the index number being or not being a part of the data model: That has nothing to do at all with wether it comes from a user input or not. You should first build you data model. I do not say that it should not contain index numbers. If you need them, by all means include them. But do so explicitly. Don't just include them in all data model just because they are useful in some cases. Then, when you have your data model, think about how to use it. E.g. how to assign those index numbers. They can for sure come from a user input. They might as well be assigned somehow automatically. I don't care. The order of the elements may be controllable by the user. But deriving the order of the elements from that in the model is wrong. When the user says he needs eggs, milk and flour then you should not translate that into 'first eggs, second milk and finally flour'. The correct translation would be 'eggs, milk and sugar and by the way he ordered eggs first, milk second and sugar third'. This means you will end up with six statements - three on the ingredients and three on the statements on the ingredients. Do not mix them. Regarding Modification date: There is quite a difference. The modification date is a statement on a subject (the wiki page) that is stored with the subject, but without modifying it. Storing the index number of a statement the way you propose, _would_ modify the statement. So, nothing broken with the Modification date, with that index, though... Cheers, Stephan On Jun 20, 2013 7:02 PM, Yaron Koren ya...@wikiworks.com wrote: Stephan - you make some good points. As far as displaying the number/index in queries - that sounds interesting, though even a separate Has index property might not necessarily be ideal for that. If you have two or more different kinds of #subobject calls on a page, it might not work out nicely. For instance, a recipe page might have subobjects for ingredients, and then subobjects for instructions. In that case, the ingredients might have Has index values of 1-10, and then the instructions might have Has index values of 11-15. (That's how numbering used to work in SIO.) So displaying this property might just look weird. Your second point is that the hash system lets SMW only display unique subobjects. Which is true, but (a) in my experience that's not a major issue, and (b) actually, sometimes you really do want to store duplicate data. What if you have a page of test scores, and you use #subobject to store each student's name and their score, and two students happen to have the same name and the same score? (Let's say that there aren't wiki pages for each student, which would force you to disambiguate.) Duplicate data might not be an error - it might be valid data. You seem to also make the point that, because it hasn't been entered by a user, the index/number isn't truly a part of the data model, and shouldn't be stored at all. Assuming you are in fact making that point, it's a reasonable opinion, but I disagree, for two reasons: (1) the order of elements is something that users can control, and thus, it is actually implicitly part of the data model, and (2) SMW already stores
Re: [SMW-devel] smw.org hooks namespace
Hi, Since you don't want to have a long bikeshed, I'll keep it short. :) I don't like the idea of having a different namespace for each page type; it seems unnecessarily complicated. If you like that specific naming structure, you could always just start page names with Hooks:, without the need for a new namespace. Personally, I don't see a big benefit to having the word Hooks in the page name at all, but that's a more minor issue. -Yaron On Sun, Jun 9, 2013 at 6:32 AM, James HK jamesin.hongkon...@gmail.comwrote: Hi, It is probably only me but I'd like to have a stable URL schema for available hooks which is could be similar to [0] and resulting in something like [1]. I don't want to have a long bikeshed over whether something like this needed or not, a stable URL without the need of being lost on some sub-page would certainly help the documentation process. [0] https://www.semantic-mediawiki.org/wiki/Hooks:Name [1] https://www.semantic-mediawiki.org/wiki/Hooks:SMW::SQLStore::PropertyTableDefinition Cheers -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [SF] Turning uploadable into input type=upload
Hi, It would be great to have an interface like that in SF - that kind of thing shows up in web forms a lot, including in the new Gmail interface, when adding email addresses. (I would like to see that kind of interface in SF for regular autocompletion too, but that's another story.) I think this would make sense as a separate input type, though (or two separate input types, or however many there would be), that would probably go into the SFI extension, since this would probably require a 3rd-party Javascript library. So this is really an unrelated issue to the syntax question, I would say. -Yaron On Thu, May 9, 2013 at 1:52 PM, Leonard Wallentin leo_wallen...@hotmail.com wrote: A special input type uploading definitely feels like the right direction to go. That would make it much easier to make (much needed) UX improvments for uploading in the future. /Leo ___ Leonard Wallentin leo_wallen...@hotmail.com @leo_wallentin +46 (0) 735 - 933 543 To: Semediawiki-devel@lists.sourceforge.net From: god.vedm...@gmail.com Date: Thu, 9 May 2013 21:47:55 +0400 CC: public-semediawiki-devel-5nwgofrqmnerv+lv9mx5uipxlwaov...@plane.gmane.org Subject: Re: [SMW-devel] [SF] Turning uploadable into input type=upload Hi, Yaron! I think standalone upload input type is a good idea. In my vision, upload input should carry only file upload case and not existing file choose case, like it can be done threw textarea/text + autocomplete on Files namespace. Simple and lightweight for users upload input like on this picture will be really usable thing: http://i.imm.io/15lne.png Such input should hide wiki-upload process from users, just allowing them to select file, they want to use. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] images as property values in PageSchemas
Hi Jamie, You're right that there are other cases where the namespace needs to be prepended - I had forgotten about that. Given that, maybe it's better to just deal with Page Schemas and template creation, instead of revisiting that entire design decision. And also given that, a single checkbox that says Uploadable? probably wouldn't be enough - the better option would probably be to have a new form input for each template field (in the Edit schema form) that said something like This field always links to pages in this namespace (leave blank if none): _. -Yaron On Wed, May 8, 2013 at 8:59 AM, Jamie Thingelstad ja...@thingelstad.comwrote: Hello Yaron, I agree that having to add the namespace in the template is confusing, but my initial reaction to adding File: if it is set to uploadable is no. Perhaps I'm being overly pedantic, but I think of a property for a page that is targeting a different namespace, most commonly I see this with a User page. If you have a field that you default=current user you need to add the namespace to that to link back to the user page. I realize that's a little apples and oranges, but still comes to mind for me. Or values from namespace= which if I'm remembering right doesn't prepend the namespace, also requiring the template to add it. So, perhaps it is worth considering more sweeping changes that add namespace clarification to a lot of things, but that would probably just introduce equal confusion the other way. My $0.02. Jamie Thingelstad http://www.thingelstad.com/ ja...@thingelstad.com mobile: 612-810-3699 find me on AIM Twitter http://twitter.com/thingles Facebookhttp://www.facebook.com/thingles LinkedIn http://www.linkedin.com/in/jthingelstad On May 7, 2013, at 3:46 PM, Yaron Koren ya...@wikiworks.com wrote: Hi, What about my suggestion? I'm also curious if anyone else has an opinion on having uploadable fields add the File: to file names. This would be a somewhat big change, so people may have opinions on it one way or another. On Tue, May 7, 2013 at 4:41 PM, Yury Katkov katkov.ju...@gmail.comwrote: For now I can just add some lines of code to the form generator: if uploadable option is here it will generate [[property::File:filename]] instead of just [[property::filename]]. I've proposed checkbox solution because of the folowing. In my opinion Page Schemas can be great visual tool to edit forms and templates very quicky. Now the editing of the schema slows because I have to look up tag parameters. More buttons, dropdowns and checkboxes could speed up the editing process. - Yury Katkov, WikiVote On Wed, May 8, 2013 at 12:28 AM, Yaron Koren ya...@wikiworks.com wrote: Hi Yury, Hm, that's true... I hadn't thought of that. Some checkbox could be added to the Page Schemas form, but maybe the better solution is just to have uploadable fields in SF start adding a File: to the beginning of file names they've uploaded. It's something that various people have asked about, but I never took that seriously - I liked the cleanliness of not including the namespace, and just having the file name. But maybe that cleanliness is more trouble than it's worth - I know that, even without this Page Schemas issue, the fact that a File: needs to be added to the template has caused a considerable amount of confusion. The main counter-argument might be that this approach is already in place on a lot of wikis, so making a change to the upload setup would require people to change a lot of existing pages; but then again, backward-compatibility can't be a reason to never make a change, and the Replace Text extension might be able to help with that sort of thing anyway. Any thoughts? -Yaron On Tue, May 7, 2013 at 4:02 PM, Yury Katkov katkov.ju...@gmail.comwrote: Hi Yaron, all! It's possible now to create uploadable fields in forms via PageSchemas: we just create a Page property and specifily the field as uploadable in additional paramerest. There is however an issue. When I generate the templates I need the File namespace to be added in front of the filename: [[someproperty::File:MyCoolPicture.jpg]] Instead I have the following: [[someproperty::MyCoolPicture.jpg]] and my image not appears on the page. Yaron, what's your advice on how to better handle that in a PageSchemas if I want to add this feature? What about adding a checkbox uploadable to the Field definition? - Yury Katkov, WikiVote -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today
Re: [SMW-devel] images as property values in PageSchemas
Hi Yury, Yes, that's what I was proposing before, but I'm no longer proposing it. :) -Yaron On Wed, May 8, 2013 at 9:22 AM, Yury Katkov katkov.ju...@gmail.com wrote: Yaron, I reread your idea but I'm not sure that I got it right Do you propose to automatically add File: text in the beginning of uploaded filename like here? http://i.imgur.com/MU31Tw9.png - Yury Katkov, WikiVote On Wed, May 8, 2013 at 4:59 PM, Jamie Thingelstad ja...@thingelstad.comwrote: Hello Yaron, I agree that having to add the namespace in the template is confusing, but my initial reaction to adding File: if it is set to uploadable is no. Perhaps I'm being overly pedantic, but I think of a property for a page that is targeting a different namespace, most commonly I see this with a User page. If you have a field that you default=current user you need to add the namespace to that to link back to the user page. I realize that's a little apples and oranges, but still comes to mind for me. Or values from namespace= which if I'm remembering right doesn't prepend the namespace, also requiring the template to add it. So, perhaps it is worth considering more sweeping changes that add namespace clarification to a lot of things, but that would probably just introduce equal confusion the other way. My $0.02. Jamie Thingelstad http://www.thingelstad.com/ ja...@thingelstad.com mobile: 612-810-3699 find me on AIM Twitter http://twitter.com/thingles Facebookhttp://www.facebook.com/thingles LinkedIn http://www.linkedin.com/in/jthingelstad On May 7, 2013, at 3:46 PM, Yaron Koren ya...@wikiworks.com wrote: Hi, What about my suggestion? I'm also curious if anyone else has an opinion on having uploadable fields add the File: to file names. This would be a somewhat big change, so people may have opinions on it one way or another. On Tue, May 7, 2013 at 4:41 PM, Yury Katkov katkov.ju...@gmail.comwrote: For now I can just add some lines of code to the form generator: if uploadable option is here it will generate [[property::File:filename]] instead of just [[property::filename]]. I've proposed checkbox solution because of the folowing. In my opinion Page Schemas can be great visual tool to edit forms and templates very quicky. Now the editing of the schema slows because I have to look up tag parameters. More buttons, dropdowns and checkboxes could speed up the editing process. - Yury Katkov, WikiVote On Wed, May 8, 2013 at 12:28 AM, Yaron Koren ya...@wikiworks.comwrote: Hi Yury, Hm, that's true... I hadn't thought of that. Some checkbox could be added to the Page Schemas form, but maybe the better solution is just to have uploadable fields in SF start adding a File: to the beginning of file names they've uploaded. It's something that various people have asked about, but I never took that seriously - I liked the cleanliness of not including the namespace, and just having the file name. But maybe that cleanliness is more trouble than it's worth - I know that, even without this Page Schemas issue, the fact that a File: needs to be added to the template has caused a considerable amount of confusion. The main counter-argument might be that this approach is already in place on a lot of wikis, so making a change to the upload setup would require people to change a lot of existing pages; but then again, backward-compatibility can't be a reason to never make a change, and the Replace Text extension might be able to help with that sort of thing anyway. Any thoughts? -Yaron On Tue, May 7, 2013 at 4:02 PM, Yury Katkov katkov.ju...@gmail.comwrote: Hi Yaron, all! It's possible now to create uploadable fields in forms via PageSchemas: we just create a Page property and specifily the field as uploadable in additional paramerest. There is however an issue. When I generate the templates I need the File namespace to be added in front of the filename: [[someproperty::File:MyCoolPicture.jpg]] Instead I have the following: [[someproperty::MyCoolPicture.jpg]] and my image not appears on the page. Yaron, what's your advice on how to better handle that in a PageSchemas if I want to add this feature? What about adding a checkbox uploadable to the Field definition? - Yury Katkov, WikiVote -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https
Re: [SMW-devel] images as property values in PageSchemas
I suppose that's true... although in practice I've never seen values get prepended with anything other than a namespace. You could have a field containing all subpage names, of course, but I've never seen that done, and on a semantic level it doesn't really make sense to do that. On the other hand, maybe that simpler wording would be clearer for users. On Wed, May 8, 2013 at 9:40 AM, Yury Katkov katkov.ju...@gmail.com wrote: And also given that, a single checkbox that says Uploadable? probably wouldn't be enough - the better option would probably be to have a new form input for each template field (in the Edit schema form) that said something like This field always links to pages in this namespace (leave blank if none): _. Hmm. The caption you've proposed is only about namespaces now. What about: Prepend the field value with the following text ? This way we will broad the usecase further. - Yury Katkov, WikiVote On Wed, May 8, 2013 at 5:26 PM, Yaron Koren ya...@wikiworks.com wrote: Hi Yury, Yes, that's what I was proposing before, but I'm no longer proposing it. :) -Yaron On Wed, May 8, 2013 at 9:22 AM, Yury Katkov katkov.ju...@gmail.comwrote: Yaron, I reread your idea but I'm not sure that I got it right Do you propose to automatically add File: text in the beginning of uploaded filename like here? http://i.imgur.com/MU31Tw9.png - Yury Katkov, WikiVote On Wed, May 8, 2013 at 4:59 PM, Jamie Thingelstad ja...@thingelstad.com wrote: Hello Yaron, I agree that having to add the namespace in the template is confusing, but my initial reaction to adding File: if it is set to uploadable is no. Perhaps I'm being overly pedantic, but I think of a property for a page that is targeting a different namespace, most commonly I see this with a User page. If you have a field that you default=current user you need to add the namespace to that to link back to the user page. I realize that's a little apples and oranges, but still comes to mind for me. Or values from namespace= which if I'm remembering right doesn't prepend the namespace, also requiring the template to add it. So, perhaps it is worth considering more sweeping changes that add namespace clarification to a lot of things, but that would probably just introduce equal confusion the other way. My $0.02. Jamie Thingelstad http://www.thingelstad.com/ ja...@thingelstad.com mobile: 612-810-3699 find me on AIM Twitter http://twitter.com/thingles Facebookhttp://www.facebook.com/thingles LinkedIn http://www.linkedin.com/in/jthingelstad On May 7, 2013, at 3:46 PM, Yaron Koren ya...@wikiworks.com wrote: Hi, What about my suggestion? I'm also curious if anyone else has an opinion on having uploadable fields add the File: to file names. This would be a somewhat big change, so people may have opinions on it one way or another. On Tue, May 7, 2013 at 4:41 PM, Yury Katkov katkov.ju...@gmail.comwrote: For now I can just add some lines of code to the form generator: if uploadable option is here it will generate [[property::File:filename]] instead of just [[property::filename]]. I've proposed checkbox solution because of the folowing. In my opinion Page Schemas can be great visual tool to edit forms and templates very quicky. Now the editing of the schema slows because I have to look up tag parameters. More buttons, dropdowns and checkboxes could speed up the editing process. - Yury Katkov, WikiVote On Wed, May 8, 2013 at 12:28 AM, Yaron Koren ya...@wikiworks.comwrote: Hi Yury, Hm, that's true... I hadn't thought of that. Some checkbox could be added to the Page Schemas form, but maybe the better solution is just to have uploadable fields in SF start adding a File: to the beginning of file names they've uploaded. It's something that various people have asked about, but I never took that seriously - I liked the cleanliness of not including the namespace, and just having the file name. But maybe that cleanliness is more trouble than it's worth - I know that, even without this Page Schemas issue, the fact that a File: needs to be added to the template has caused a considerable amount of confusion. The main counter-argument might be that this approach is already in place on a lot of wikis, so making a change to the upload setup would require people to change a lot of existing pages; but then again, backward-compatibility can't be a reason to never make a change, and the Replace Text extension might be able to help with that sort of thing anyway. Any thoughts? -Yaron On Tue, May 7, 2013 at 4:02 PM, Yury Katkov katkov.ju...@gmail.comwrote: Hi Yaron, all! It's possible now to create uploadable fields in forms via PageSchemas: we just create a Page property and specifily the field as uploadable in additional paramerest. There is however an issue. When I generate the templates I need the File namespace to be added in front
[SMW-devel] [SF] Turning uploadable into input type=upload
Hi, I'm turning this into another thread, since I think it's unrelated to the original topic - I believe the namespace issue is the same regardless of the form field syntax. I think it makes sense to keep it as uploadable instead of turning it into a separate input type, because it can have all the variations of standard text inputs - it can be either a text or a textarea field, it can have all the autocompletion options, etc. There's nothing that says that every value that goes into an uploadable field has to be uploaded with that form; so autocompletion may be useful there. -Yaron On Wed, May 8, 2013 at 10:23 AM, Yury Katkov katkov.ju...@gmail.com wrote: The current implementation seems weird for me too. It's very clear that 'uploadable' is a distinct form input and not the parameter of some other form input. What was the rational behind that? - Yury Katkov, WikiVote On Wed, May 8, 2013 at 6:14 PM, Jamie Thingelstad ja...@thingelstad.comwrote: Just to throw out an alternative suggestion since we are on the topic. What about handling uploadable fields as there own input type? We currently have: {{{field|Image|uploadable|image preview|default=Default website image.png}}} what if it was something like: {{{field|Image|input type=upload|preview|default=Default website image.png}}} It is nice to be able to reuse the generic input type for pages for uploadable content, but, I could see optimizations. Some thoughts: - This would allow the File namespace to be prepended automatically if so desired, considering it a different input type. - It could allow (in the future) for a more pleasant upload experience than the current iframe of the upload form (one of the most confusing aspects of MediaWiki for new users in my experience). - It could allow new things like this must be a PDF with require filetype=pdf or something. Just an idea. It feels like a good direction to me. And backwards compatibility could be maintained for some period of time. Jamie Thingelstad http://www.thingelstad.com/ ja...@thingelstad.com mobile: 612-810-3699 find me on AIM Twitter http://twitter.com/thingles Facebookhttp://www.facebook.com/thingles LinkedIn http://www.linkedin.com/in/jthingelstad On May 8, 2013, at 9:01 AM, Yaron Koren ya...@wikiworks.com wrote: I suppose that's true... although in practice I've never seen values get prepended with anything other than a namespace. You could have a field containing all subpage names, of course, but I've never seen that done, and on a semantic level it doesn't really make sense to do that. On the other hand, maybe that simpler wording would be clearer for users. On Wed, May 8, 2013 at 9:40 AM, Yury Katkov katkov.ju...@gmail.comwrote: And also given that, a single checkbox that says Uploadable? probably wouldn't be enough - the better option would probably be to have a new form input for each template field (in the Edit schema form) that said something like This field always links to pages in this namespace (leave blank if none): _. Hmm. The caption you've proposed is only about namespaces now. What about: Prepend the field value with the following text ? This way we will broad the usecase further. - Yury Katkov, WikiVote On Wed, May 8, 2013 at 5:26 PM, Yaron Koren ya...@wikiworks.com wrote: Hi Yury, Yes, that's what I was proposing before, but I'm no longer proposing it. :) -Yaron On Wed, May 8, 2013 at 9:22 AM, Yury Katkov katkov.ju...@gmail.comwrote: Yaron, I reread your idea but I'm not sure that I got it right Do you propose to automatically add File: text in the beginning of uploaded filename like here? http://i.imgur.com/MU31Tw9.png - Yury Katkov, WikiVote On Wed, May 8, 2013 at 4:59 PM, Jamie Thingelstad ja...@thingelstad.com wrote: Hello Yaron, I agree that having to add the namespace in the template is confusing, but my initial reaction to adding File: if it is set to uploadable is no. Perhaps I'm being overly pedantic, but I think of a property for a page that is targeting a different namespace, most commonly I see this with a User page. If you have a field that you default=current user you need to add the namespace to that to link back to the user page. I realize that's a little apples and oranges, but still comes to mind for me. Or values from namespace= which if I'm remembering right doesn't prepend the namespace, also requiring the template to add it. So, perhaps it is worth considering more sweeping changes that add namespace clarification to a lot of things, but that would probably just introduce equal confusion the other way. My $0.02. Jamie Thingelstad http://www.thingelstad.com/ ja...@thingelstad.com mobile: 612-810-3699 find me on AIM Twitter http://twitter.com/thingles Facebookhttp://www.facebook.com/thingles LinkedIn http://www.linkedin.com/in/jthingelstad On May 7, 2013, at 3:46 PM, Yaron Koren
Re: [SMW-devel] [SF] Turning uploadable into input type=upload
Hi, There are indeed times when it makes sense to use a textarea, and I believe that's been done. If the field can hold a lot of file names, a textarea makes it easier to see all of them. -Yaron On Wed, May 8, 2013 at 11:04 AM, Yury Katkov katkov.ju...@gmail.com wrote: Hi Yaron! I don't know neither if 'textarea+uploadable' makes a lot of sense nor if it's used by anyone. Let us forget for a minute about textarea+uploadable and focus on text+uploadable. I think it's possible to create a input type=uploadable that will be inherited from input type=text and will have all autocompletion functons. Yury Katkov, WikiVote On Wed, May 8, 2013 at 6:34 PM, Yaron Koren ya...@wikiworks.com wrote: Hi, I'm turning this into another thread, since I think it's unrelated to the original topic - I believe the namespace issue is the same regardless of the form field syntax. I think it makes sense to keep it as uploadable instead of turning it into a separate input type, because it can have all the variations of standard text inputs - it can be either a text or a textarea field, it can have all the autocompletion options, etc. There's nothing that says that every value that goes into an uploadable field has to be uploaded with that form; so autocompletion may be useful there. -Yaron On Wed, May 8, 2013 at 10:23 AM, Yury Katkov katkov.ju...@gmail.comwrote: The current implementation seems weird for me too. It's very clear that 'uploadable' is a distinct form input and not the parameter of some other form input. What was the rational behind that? - Yury Katkov, WikiVote On Wed, May 8, 2013 at 6:14 PM, Jamie Thingelstad ja...@thingelstad.com wrote: Just to throw out an alternative suggestion since we are on the topic. What about handling uploadable fields as there own input type? We currently have: {{{field|Image|uploadable|image preview|default=Default website image.png}}} what if it was something like: {{{field|Image|input type=upload|preview|default=Default website image.png}}} It is nice to be able to reuse the generic input type for pages for uploadable content, but, I could see optimizations. Some thoughts: - This would allow the File namespace to be prepended automatically if so desired, considering it a different input type. - It could allow (in the future) for a more pleasant upload experience than the current iframe of the upload form (one of the most confusing aspects of MediaWiki for new users in my experience). - It could allow new things like this must be a PDF with require filetype=pdf or something. Just an idea. It feels like a good direction to me. And backwards compatibility could be maintained for some period of time. Jamie Thingelstad http://www.thingelstad.com/ ja...@thingelstad.com mobile: 612-810-3699 find me on AIM Twitter http://twitter.com/thingles Facebookhttp://www.facebook.com/thingles LinkedIn http://www.linkedin.com/in/jthingelstad On May 8, 2013, at 9:01 AM, Yaron Koren ya...@wikiworks.com wrote: I suppose that's true... although in practice I've never seen values get prepended with anything other than a namespace. You could have a field containing all subpage names, of course, but I've never seen that done, and on a semantic level it doesn't really make sense to do that. On the other hand, maybe that simpler wording would be clearer for users. On Wed, May 8, 2013 at 9:40 AM, Yury Katkov katkov.ju...@gmail.comwrote: And also given that, a single checkbox that says Uploadable? probably wouldn't be enough - the better option would probably be to have a new form input for each template field (in the Edit schema form) that said something like This field always links to pages in this namespace (leave blank if none): _. Hmm. The caption you've proposed is only about namespaces now. What about: Prepend the field value with the following text ? This way we will broad the usecase further. - Yury Katkov, WikiVote On Wed, May 8, 2013 at 5:26 PM, Yaron Koren ya...@wikiworks.comwrote: Hi Yury, Yes, that's what I was proposing before, but I'm no longer proposing it. :) -Yaron On Wed, May 8, 2013 at 9:22 AM, Yury Katkov katkov.ju...@gmail.comwrote: Yaron, I reread your idea but I'm not sure that I got it right Do you propose to automatically add File: text in the beginning of uploaded filename like here? http://i.imgur.com/MU31Tw9.png - Yury Katkov, WikiVote On Wed, May 8, 2013 at 4:59 PM, Jamie Thingelstad ja...@thingelstad.com wrote: Hello Yaron, I agree that having to add the namespace in the template is confusing, but my initial reaction to adding File: if it is set to uploadable is no. Perhaps I'm being overly pedantic, but I think of a property for a page that is targeting a different namespace, most commonly I see this with a User page. If you have a field that you default=current user you need to add
Re: [SMW-devel] images as property values in PageSchemas
Hi Yury, Hm, that's true... I hadn't thought of that. Some checkbox could be added to the Page Schemas form, but maybe the better solution is just to have uploadable fields in SF start adding a File: to the beginning of file names they've uploaded. It's something that various people have asked about, but I never took that seriously - I liked the cleanliness of not including the namespace, and just having the file name. But maybe that cleanliness is more trouble than it's worth - I know that, even without this Page Schemas issue, the fact that a File: needs to be added to the template has caused a considerable amount of confusion. The main counter-argument might be that this approach is already in place on a lot of wikis, so making a change to the upload setup would require people to change a lot of existing pages; but then again, backward-compatibility can't be a reason to never make a change, and the Replace Text extension might be able to help with that sort of thing anyway. Any thoughts? -Yaron On Tue, May 7, 2013 at 4:02 PM, Yury Katkov katkov.ju...@gmail.com wrote: Hi Yaron, all! It's possible now to create uploadable fields in forms via PageSchemas: we just create a Page property and specifily the field as uploadable in additional paramerest. There is however an issue. When I generate the templates I need the File namespace to be added in front of the filename: [[someproperty::File:MyCoolPicture.jpg]] Instead I have the following: [[someproperty::MyCoolPicture.jpg]] and my image not appears on the page. Yaron, what's your advice on how to better handle that in a PageSchemas if I want to add this feature? What about adding a checkbox uploadable to the Field definition? - Yury Katkov, WikiVote -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] images as property values in PageSchemas
Hi, What about my suggestion? I'm also curious if anyone else has an opinion on having uploadable fields add the File: to file names. This would be a somewhat big change, so people may have opinions on it one way or another. On Tue, May 7, 2013 at 4:41 PM, Yury Katkov katkov.ju...@gmail.com wrote: For now I can just add some lines of code to the form generator: if uploadable option is here it will generate [[property::File:filename]] instead of just [[property::filename]]. I've proposed checkbox solution because of the folowing. In my opinion Page Schemas can be great visual tool to edit forms and templates very quicky. Now the editing of the schema slows because I have to look up tag parameters. More buttons, dropdowns and checkboxes could speed up the editing process. - Yury Katkov, WikiVote On Wed, May 8, 2013 at 12:28 AM, Yaron Koren ya...@wikiworks.com wrote: Hi Yury, Hm, that's true... I hadn't thought of that. Some checkbox could be added to the Page Schemas form, but maybe the better solution is just to have uploadable fields in SF start adding a File: to the beginning of file names they've uploaded. It's something that various people have asked about, but I never took that seriously - I liked the cleanliness of not including the namespace, and just having the file name. But maybe that cleanliness is more trouble than it's worth - I know that, even without this Page Schemas issue, the fact that a File: needs to be added to the template has caused a considerable amount of confusion. The main counter-argument might be that this approach is already in place on a lot of wikis, so making a change to the upload setup would require people to change a lot of existing pages; but then again, backward-compatibility can't be a reason to never make a change, and the Replace Text extension might be able to help with that sort of thing anyway. Any thoughts? -Yaron On Tue, May 7, 2013 at 4:02 PM, Yury Katkov katkov.ju...@gmail.comwrote: Hi Yaron, all! It's possible now to create uploadable fields in forms via PageSchemas: we just create a Page property and specifily the field as uploadable in additional paramerest. There is however an issue. When I generate the templates I need the File namespace to be added in front of the filename: [[someproperty::File:MyCoolPicture.jpg]] Instead I have the following: [[someproperty::MyCoolPicture.jpg]] and my image not appears on the page. Yaron, what's your advice on how to better handle that in a PageSchemas if I want to add this feature? What about adding a checkbox uploadable to the Field definition? - Yury Katkov, WikiVote -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [SF] plans on integrating VisualEditor with Semantic Forms
Hi Yury, I would definitely like to see SF support VisualEditor, whether it's me or someone else adding that support. I wasn't aware that VisualEditor was being used yet on Wikipedia (other than I guess in demo areas), or even that it was in a usable state. Where is it being used? -Yaron On Mon, May 6, 2013 at 7:55 AM, Yury Katkov katkov.ju...@gmail.com wrote: Hi Yaron! So Visual Editor is now working on Wikipedias and that means that it's mature enough and its code is less likely to dramatically change over time. The same follows from the Roadmap [1]. Yaron, do you have any plans on integrating VisualEditor with Semantic Forms? I address the same question to other developers: if you have intentions to integrat SF and VE, maybe we can work together? [1] https://docs.google.com/spreadsheet/ccc?key=0Aoizbfxc5g6KdEkza0xkQnJlM0o0TXlwQXhDOUFvYnc#gid=0 - Yury Katkov, WikiVote -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [SF] plans on integrating VisualEditor with Semantic Forms
Ah! I guess I had seen that before, actually, but then had forgotten about it. I tried it out - VisualEditor definitely seems to have some problems handling template calls (not even editing them, which it can't do yet, but just treating them normally when you modify the text around them); but then again, if forms are being used, there's a reasonable chance that there won't be any template calls in the free text, so it's probably not a big deal. So, to answer your question again, I still have no immediate plans to add VisualEditor support, but it's definitely something I'd like to see happen. On Mon, May 6, 2013 at 8:58 AM, Yury Katkov katkov.ju...@gmail.com wrote: It's now enabled on 15 language wikis and on mediawiki.org: https://blog.wikimedia.org/2013/04/25/visualeditor-alpha-in-15-languages/ Go to Special:Settings to enable it. - Yury Katkov, WikiVote On Mon, May 6, 2013 at 4:51 PM, Yaron Koren ya...@wikiworks.com wrote: Hi Yury, I would definitely like to see SF support VisualEditor, whether it's me or someone else adding that support. I wasn't aware that VisualEditor was being used yet on Wikipedia (other than I guess in demo areas), or even that it was in a usable state. Where is it being used? -Yaron On Mon, May 6, 2013 at 7:55 AM, Yury Katkov katkov.ju...@gmail.comwrote: Hi Yaron! So Visual Editor is now working on Wikipedias and that means that it's mature enough and its code is less likely to dramatically change over time. The same follows from the Roadmap [1]. Yaron, do you have any plans on integrating VisualEditor with Semantic Forms? I address the same question to other developers: if you have intentions to integrat SF and VE, maybe we can work together? [1] https://docs.google.com/spreadsheet/ccc?key=0Aoizbfxc5g6KdEkza0xkQnJlM0o0TXlwQXhDOUFvYnc#gid=0 - Yury Katkov, WikiVote -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Multilingual Semantic MediaWiki
Hi Niklas, This sounds like a great idea. I can't really help, since I would think the majority of the challenge would be in getting SMW queries to recognize different property names as equivalent, so I would think this would require assistance or at least advice from a core SMW developer; but hopefully one of them would be willing to help out. And this sounds like a reasonable project size. If there's one thing you can learn from going through the list of the Wikimedia Foundation's past projects for GSoC, it's that too little work for GSoC is rarely an issue. :) -Yaron On Fri, Apr 26, 2013 at 11:57 AM, Niklas Laxström niklas.laxst...@gmail.com wrote: This is an idea I proposed for GSoC (as in a topic for a student). Some links: http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Multilingual_SemanticMediaWiki https://bugzilla.wikimedia.org/46522 I've been trying to create a multilingual semantic mediawiki and found it it is not easy nor possible to do it properly right now. Since I am a developer of Translate extension I started thinking that these two could be integrated. There are multiple parts to reaching the end goal, and I can think of at least three clearly separate ones: 1) Multilingual forms Idea: When creating a form, you could choose to create a multilingual form. In place of field labels there would be {{int:prefix-fieldname}} calls that would pull translated version. Same for buttons and other elements. The special page creating the form would also create all necessary MediaWiki:prefix-fieldname messages having the default text. This all can be done with plain MediaWiki. But it gets more useful if integrated with the Translate extension [1]. SemanticForms can register the group of messages belonging to the form as a message group in Translate. Then it could be translated like anything else with the translation editor, have statistics etc. Together with the UniversalLanguageSelector [2] extension the users will see translation version of the form in their language if it is available. Some examples of this done manually: [3][4] 2) Multilingual templates The same can be done for the templates that display the semantic properties 3) Multilingual properties The names of properties could also be translated in similar way. The names are displayed on various places: special pages, query results, page names etc. The three things above wont solve the problem of handling multilingual content as values of semantic properties, but nevertheless it would be great help to provide multilingual interface to the data. Questions: * Is anyone willing to co-mentor this project with me? We have a potential student for it. * Any implementation blockers or flaws in this idea? Is this too much or too little for GSoC? * Do you like the idea? [1] https://www.mediawiki.org/wiki/Help:Extension:Translate [2] https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector [3] http://tieteentermipankki.fi/mediawiki/index.php?title=Lomake:K%C3%A4siteaction=edit [4] http://tieteentermipankki.fi/wiki/Toiminnot:K%C3%A4%C3%A4nn%C3%A4?group=wiki-form-concept -Niklas -- Niklas Laxström -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [SIO] Querying internal object properties
Hi, This seems like a bad hack. I assume this is part of your effort to have the page store the usernames of all its contributors? If so, the Semantic Extra Special Properties extension may be the better approach - I believe it stores that information using the Page author property: https://www.mediawiki.org/wiki/Extension:Semantic_Extra_Special_Properties -Yaron On Sat, Apr 20, 2013 at 3:05 PM, Marcelo Chiaradía chiaradiamarc...@gmail.com wrote: Hi everyone, I have saved an internal object which has several properties: {{#set_internal:isInternalObjectOf |property1=value1 |property2=value2 |name=object_name }} I have a situation where eventually I need to define a new internal object using the properties of the object saved before as values. The way I found to do this is through semantic queries: {{#set_internal:isInternalObjectOf |property1={{#ask: [[-property1::[[name::object_name]] ]]}} |property2={{#ask: [[-property2::[[name::object_name]] ]]}} }} The sintax may be not quite correct, just to show the idea. The problem with this approach is that for every property, I have to make a new query. Is there some way to do this with only one query? Thanks in advance. Marcelo. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [SIO] Querying internal object properties
The more relevant question, to me, is *why* you would want to do any of this. The whole point of a wiki is to be able to collaboratively create content, where it doesn't really matter who added what. So why you need to query on this data? On Sun, Apr 21, 2013 at 1:03 PM, Marcelo Chiaradía chiaradiamarc...@gmail.com wrote: Yeah, I know. I've been checking the Semantic Extra Special Properties extension, but it only solves half of my problem. This is my situation: I need to save somehow the author that made a contribution to a page, and somehow classify it regarding the information modified by him. First I thought an easy solution including a checkbox in the semantic form for the classification problem (like is minor edit), but it looks a lot more complex. So now Im considering the develop of my own extension to semantify this information, following the Semantic Extra Special Properties and s13n approach. I guess there's no easier way to do it, rigth? Cheers, Marcelo. 2013/4/21 Yaron Koren ya...@wikiworks.com Hi, This seems like a bad hack. I assume this is part of your effort to have the page store the usernames of all its contributors? If so, the Semantic Extra Special Properties extension may be the better approach - I believe it stores that information using the Page author property: https://www.mediawiki.org/wiki/Extension:Semantic_Extra_Special_Properties -Yaron On Sat, Apr 20, 2013 at 3:05 PM, Marcelo Chiaradía chiaradiamarc...@gmail.com wrote: Hi everyone, I have saved an internal object which has several properties: {{#set_internal:isInternalObjectOf |property1=value1 |property2=value2 |name=object_name }} I have a situation where eventually I need to define a new internal object using the properties of the object saved before as values. The way I found to do this is through semantic queries: {{#set_internal:isInternalObjectOf |property1={{#ask: [[-property1::[[name::object_name]] ]]}} |property2={{#ask: [[-property2::[[name::object_name]] ]]}} }} The sintax may be not quite correct, just to show the idea. The problem with this approach is that for every property, I have to make a new query. Is there some way to do this with only one query? Thanks in advance. Marcelo. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [Semediawiki-user] Wikitech-l discussion / Is SMW a bloated piece of software ?
Hi, Thanks for the Semantic Forms appreciation. Just to clarify, though, the person you quoted is trueskew, not James HK. -Yaron On Thu, Apr 4, 2013 at 11:50 PM, Al Johnson alj62...@yahoo.com wrote: +1 All of that said, I would never select Mediawiki / Semantic Mediawiki if Semantic Forms and RunQuery were not available to hide Mediawiki / Semantic Mediawiki syntax. -James HK Semantic Forms is critical to SMW's success, imo. al -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Semediawiki-user mailing list semediawiki-u...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-user -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [Semediawiki-user] Wikitech-l discussion / Is SMW a bloated piece of software ?
I've been following the discussion over there, though I haven't gotten involved (though it seems to have died down by now). A lot of the resistance to SMW is part of a longstanding dislike, or at least lack of understanding, of SMW among core MediaWiki developers; though as Niklas points out, it does seem to have decreased this time around. Though the fact that it's taken basically seven years for that shift to have occurred is somewhat depressing. :) Actually, I think a lot of the shift can be attributed to the efforts of just a few people: Ryan Lane at WMF operations, and Niklas and Siebrand on the Translatewiki team. My only other comment is about performance: someone on the wikitech-l thread noted that Wikia has had performance problems with SMW on some of their sites, which is true; but I've talked to the Wikia people, and I think just about all of these issues can be traced to their use of Semantic Drilldown. SD (an extension I wrote) is useful but can overload the database if it's used indiscriminately on larger sites. I've given them tips on how to reduce the performance impact of SD - I don't know if they've taken any of them. But given that, I don't think the Wikia experience, at least, applies to Wikitech or mediawiki.org. -Yaron -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Semantic forms using variables in more than one template
Hi Mary, The easiest approach is to just have that template query the other values, using #show. -Yaron On Thu, Mar 7, 2013 at 3:36 PM, Beebe, Mary J bee...@battelle.org wrote: We have a form using more than one template. One of the templates is like an info-box. It displays all of the properties within the page in a nice format (better than the built in factbox or Browse Properties) . ** ** All the properties are set within the form. Is there a nice way to get the form variables to this template even though they have their own template. ** ** Within http://www.mediawiki.org/wiki/Extension:Semantic_Forms/Defining_forms I noticed the “embed infield” attribute within the “for template” tag. I am not sure what that does. Would that be helpful for this case? ** ** Thanks, ** ** Mary Beebe ** ** -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Tag for SB in git?
Hi Dan, Yes, a lot of what you're talking about (and discovering, I guess) was discussed in two email threads yesterday, on the semediawiki-user list. It would indeed be nice if the remaining untagged extensions were tagged, and if SB started to have tagging as well. It wouldn't make a huge impact, though, since SB is mostly used by people who don't have Git (and, previously, SVN) on their systems. -Yaron On Tue, Feb 26, 2013 at 8:34 AM, Dan Bolser dan.bol...@gmail.com wrote: I've just noticed these releases: https://code.google.com/p/semantic-mediawiki-bundle/downloads/list Seems those releases can't be tagged in the git repo because they again rely on checking out HEAD code of various other extensions... It would be great if those extensions could be tagged, then SB could also be tagged. Cheers, Dan. On 26 February 2013 13:24, Dan Bolser dan.bol...@gmail.com wrote: On 26 February 2013 13:19, Dan Bolser dan.bol...@gmail.com wrote: I may be doing something wrong, but I don't see any tags for SB in git: git remote -v origin https://gerrit.wikimedia.org/r/p/mediawiki/extensions/SemanticBundle.git (fetch) origin https://gerrit.wikimedia.org/r/p/mediawiki/extensions/SemanticBundle.git (push) git tag # No output I'm asking because currently HEAD has entries like this for SemanticMediaWiki and SemanticResultFormats: SemanticMediaWiki 1.8.x SemanticResultFormats 1.8.x There is no such branch or tag in the repos for those extensions, so it ends up being the current HEAD, wherever that happens to be when Ahh... I think I was missing a git pull to see those branches (else I'm just blind). I think the point below is still valid though: you make. This seems contrary to the idea of the bundle... Actually, a few other extension are listed as HEAD (master). Am I missing something? i.e. is what's in these repos never actually development code, always being tagged or branched from some other repo? If not, it seems risky to allow 'bundles' to differ depending on when they were created (nominally the same bundle). Cheers, Dan. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] SMW and LTS
Hi Stephan, There are a number of points to discuss here. In our case, I think long-term support really refers to two things: support for older versions of MediaWiki, and support for older versions of SMW. I don't know if everyone's aware of it, but the WMF people have actually declared MediaWiki 1.19 to be the official LTS version for the next two years - so people are supposed to be able to use 1.19 for the next two years without any worries. See here: http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064277.html In the case of the Semantic Bundle, only compatibility with MediaWiki matters, since SMW is included in the bundle. But then again, maybe everyone is just talking about support for MediaWiki? Anyway, the best approach for long-term support, in my opinion, is to have each extension individually maintain support for older versions of MediaWiki - especially version 1.19. (And for older versions of SMW, especially if some version of it is declared the LTS version.) That way there doesn't need to be special coordination done for the Semantic Bundle, and of course it means that the benefits still apply to people who download the extensions in other ways. I try to maintain support for older versions of MediaWiki in all my extensions, going back two or more years if possible. Currently most of my extensions support MediaWiki 1.17, which came out in June 2011 - and the jump to 1.17 was only because of the major change in that version with the ResourceLoader. It's not that hard to maintain backward compatibility, and I think it's the right option, when possible - certainly easier than holding different branches and trying to maintain all of them. I'm not unique in this - the Semantic Forms Inputs and Semantic Maps extensions, other SB extensions maintained by other people (both on this thread), also still support MediaWiki 1.17, for instance. And so does SMW itself, for that matter - though the SMW page says that MediaWiki 1.19 is recommended, whatever that means. So could it be that the solution to this is to simply highly recommend to all extension developers to keep support for older versions of MediaWiki, now and in the future? -Yaron On Mon, Feb 25, 2013 at 8:30 AM, Stephan Gambke s7ep...@gmail.com wrote: Ok, digging this out again. On 5 December 2012 22:39, James HK jamesin.hongkon...@gmail.com wrote: # What would LTS mean in connection with SMW ? Provide LTS versions of the Semantic Bundle. This would mean: * to branch off versions* of SMW * to include updated versions of extensions in the Semantic Bundle as long as they support the relevant SMW version * to branch off versions of these extensions once they stop supporting the relevant SMW version * to clearly state extensions contained in the bundle including their versions * to clearly state compatibility of the bundle to MW versions * to apply patches to contained extensions if somebody provides them * Considered versions of SMW would be the last minor versions before the release of a new major version of SMW, i.e. 1.5.6, 1.6.1, 1.7.1, ... Of these only take one per year and support it for two(?) years. This would mean 1.6.1 (2011), 1.8 (2012), and 1.10 (2013). # Which implications would LTS have on future developments ? Extension developers should anounce new versions of their extensions stating compatibility of their extension to MW and SMW. They should tag release versions of their extensions in git. They should also think about if a bug or feature is important enough to be backported. # Why would SMW need/want to support a LTS infrastructure ? What would be the benefit ? Availability of stable Semantic Bundles on older MWs, giving people more time to plan their updates and allow them to do updates less often. # Who will do LTS for SMW and what infrastructure is needed to support LTS (own branch etc.) I would do the administration work incl. applying patches. I would in general not do backporting. I would propose to keep download versions on Google Code along with the regular packages and document the contents on semantic-mediawiki.org and/or mediawiki.org, e.g. as subpages of the extension page. # Would LTS mean a freeze release or do features from a development branch are back ported to a LTS? See above. Basically freeze for SMW and extensions that don't support the frozen SMW anymore. Patches applied if provided. What do you think? # SMW 1.8 supports MW 1.17/1.18+ # SMW 1.9 is planned to support MW 1.19/1.20/1.21 / PHP 5.3 or greater # SMW 1.10 is planned to support MW 1.20 (or 1.21 pending on the release date) Maybe think about that again. SMW 1.6 to 1.8 all supported up to two year old MW versions. With the roadmap as it is this would drop to one year for 1.9. SMW - MW: Delay 1.6 (30/07/2011) - 1.15 (25/03/2009): 2.3 years 1.6.1 (20/08/2011) - 1.15 (25/03/2009): 2.4 years 1.7 (01/01/2012) - 1.16 (22/02/2010): 1.9 years 1.7.1
Re: [SMW-devel] Semantic Bundle and MW tarball
Hi Mark, It sounds like a good idea to me. What version of MediaWiki would you want to start with - 1.20 (the current version), I assume? And where do you think it makes sense to host and document these packages? -Yaron On Mon, Feb 25, 2013 at 1:31 PM, Mark A. Hershberger m...@everybody.orgwrote: As Yaron suggested, this is a new thread to discuss possible MediaWiki tarballs shipping with the Semantic Bundle. Many people want to use SMW when they install MediaWiki, so shipping it all as one big bundle makes sense to me. I think it would also makes some of the support issues easier. For example, when looking for the Semantic Bundle that is targeted to MW 1.21, they wouldn't have to track down old versions, check dates, etc. There would be a single file to download. Since most (all?) of the extensions in the Semantic Bundle are in git, it shouldn't be too hard to create one. -- http://hexmode.com/ There is no path to peace. Peace is the path. -- Mahatma Gandhi, Non-Violence in Peace and War -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] SMW and LTS
Hi Stephan, Yes, I know that the the transfer to Git threw off a lot in terms of consistent tagging - that's the main part of the reason why there have been only two Semantic Bundle releases since the changeover happened a year ago. In any case, anything you can do to improve the state of tagging and compatibility is definitely appreciated! -Yaron On Mon, Feb 25, 2013 at 1:56 PM, Stephan Gambke s7ep...@gmail.com wrote: Hi Yaron, On 02/25/2013 07:24 PM, Yaron Koren wrote: As to creating new Semantic Bundles on the fly that match some criteria - i.e., using some set of Git tags - that gets complicated by the fact that not all of the extensions have consistent tagging. Some (like, I'm Yeah, that was one of the requirements to the developers - tag release versions of their extensions in git. afraid to say, Semantic Forms Inputs, don't have any tags) - there are Ouch, that hurt. :D That's only because there was no release of SFI since the switch to git. Have a look at the old SVN repo and you will find tags galore. the automatic tags applied for MediaWiki versions, but those are not reliable as far as guaranteeing either compatibility or stability of the code. Agreed, they will not help. In general, ensuring the compatibility of Semantic Bundle is about the level of difficulty one would expect for a package holding 22 extensions, with varying levels of maintenance for each. Of course, some Ok, I'd still like to give it a try. If it does not work, we are not worse off. If it does work, me pestering the devs might actually get them to tag their extensions consistently and think about and state compatibility. Cheers, Stephan -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Semantic Bundle and MW tarball
Hi, Mark - that sounds like a good idea. We're actually going to have another release of Semantic Bundle in the near future, that should fix some remaining issues; so I think it would be a good candidate for trying to create this kind of package. John - the criteria for inclusion in the Semantic Bundle are set by its maintainers: me, Jeroen and Sergey. I should note that SB is not an official SMW product. -Yaron On Mon, Feb 25, 2013 at 3:11 PM, jmccl...@hypergrove.com wrote: ** Hi - where can I find more information about how the MW installer and the extensions it installs? And I'm also wondering what the criteria are for an extension to be part of the SMW bundle? thanks - john On 25.02.2013 12:01, Mark A. Hershberger wrote: On Mon 25 Feb 2013 02:12:41 PM EST, Yaron Koren wrote: It sounds like a good idea to me. What version of MediaWiki would you want to start with - 1.20 (the current version), I assume? At the latest, we could do 1.21. Earliest I would go is 1.19. But 1.20 is a good place to start. Since the MW installer can also install extensions (as it does for those it is shipped with) one thing we would need to do is make sure any shipping extensions can be installed with the installer. If the installer needs to be fixed, to do this then we'll have to limit this to 1.21 onwards (but it may be worthwhile to fix any bugs in 1.20 or 1.19). And where do you think it makes sense to host and document these packages? I think it would make sense to host them with the regular MediaWiki tarballs, but assuming that isn't do-able (I would need to ask and I think Ariel already wanted to change were the tarballs were hosted), why not add them to the SF dowload page? Maybe we could put them on toolserver.org? As far as documenting, I think https://www.mediawiki.org/wiki/Semantic_Bundle and http://www.semantic-mediawiki.org/wiki/Semantic_Bundle make a lot of sense. Linking to the bundle page and download link from the front page of SMW.org also makes sense. Of course, I'm open to any other ideas you have for documentation and hosting. --http://hexmode.com/ There is no path to peace. Peace is the path. -- Mahatma Gandhi, Non-Violence in Peace and War -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Semediawiki-devel mailing listSemediawiki-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel