Re: [SMW-devel] Modern chat solution as alternative to IRC?

2017-07-27 Thread Yaron Koren
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 Lampa 
wrote:

> 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

2016-12-15 Thread Yaron Koren
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, Viktor  wrote:

> 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

2016-10-05 Thread Yaron Koren
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

2016-10-04 Thread Yaron Koren
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  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-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel


Re: [SMW-devel] ApprovedRevs + SMW

2016-04-29 Thread Yaron Koren
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, Vedmaka  wrote:

> 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

2015-10-09 Thread Yaron Koren
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 HK 
wrote:

> 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

2015-09-15 Thread Yaron Koren
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 Gil 
Date: 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?

2015-06-29 Thread Yaron Koren
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

2015-05-29 Thread Yaron Koren
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

2015-05-28 Thread Yaron Koren
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

2015-04-05 Thread Yaron Koren
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

2015-04-03 Thread Yaron Koren
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

2015-03-31 Thread Yaron Koren
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

2015-03-31 Thread Yaron Koren
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

2015-03-31 Thread Yaron Koren
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

2015-03-31 Thread Yaron Koren
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

2015-03-31 Thread Yaron Koren
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

2015-03-26 Thread Yaron Koren
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

2015-03-26 Thread Yaron Koren
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

2014-11-13 Thread Yaron Koren
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?)

2014-11-10 Thread Yaron Koren
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

2014-10-08 Thread Yaron Koren
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

2014-09-24 Thread Yaron Koren
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

2014-07-29 Thread Yaron Koren
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

2014-07-29 Thread Yaron Koren
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

2014-07-22 Thread Yaron Koren
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

2014-07-22 Thread Yaron Koren
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

2014-07-21 Thread Yaron Koren
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

2014-07-21 Thread Yaron Koren
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

2014-07-21 Thread Yaron Koren
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?

2014-07-18 Thread Yaron Koren
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?

2014-07-16 Thread Yaron Koren
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?

2014-07-16 Thread Yaron Koren
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?

2014-07-16 Thread Yaron Koren
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?

2014-07-16 Thread Yaron Koren
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?

2014-07-15 Thread Yaron Koren
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

2014-07-11 Thread Yaron Koren
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

2014-07-09 Thread Yaron Koren
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

2014-05-16 Thread Yaron Koren
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

2014-05-02 Thread Yaron Koren
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

2014-05-02 Thread Yaron Koren
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

2014-02-11 Thread Yaron Koren
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

2014-02-11 Thread Yaron Koren
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

2014-01-27 Thread Yaron Koren
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

2014-01-27 Thread Yaron Koren
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?

2014-01-20 Thread Yaron Koren
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

2014-01-16 Thread Yaron Koren
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

2014-01-10 Thread Yaron Koren
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

2013-12-17 Thread Yaron Koren
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

2013-12-17 Thread Yaron Koren
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

2013-11-26 Thread Yaron Koren
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

2013-11-25 Thread Yaron Koren
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?

2013-11-20 Thread Yaron Koren
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?

2013-11-20 Thread Yaron Koren
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

2013-11-19 Thread Yaron Koren
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

2013-11-17 Thread Yaron Koren
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

2013-11-17 Thread Yaron Koren
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?

2013-11-11 Thread Yaron Koren
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

2013-11-06 Thread Yaron Koren
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

2013-11-01 Thread Yaron Koren
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

2013-10-24 Thread Yaron Koren
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

2013-10-24 Thread Yaron Koren
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?

2013-10-22 Thread Yaron Koren
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

2013-10-01 Thread Yaron Koren
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

2013-09-23 Thread Yaron Koren
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?

2013-09-19 Thread Yaron Koren
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

2013-09-12 Thread Yaron Koren
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

2013-08-16 Thread Yaron Koren
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)

2013-08-11 Thread Yaron Koren
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)

2013-08-08 Thread Yaron Koren
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)

2013-08-08 Thread Yaron Koren
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)

2013-08-08 Thread Yaron Koren
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

2013-06-28 Thread Yaron Koren
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

2013-06-21 Thread Yaron Koren
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

2013-06-20 Thread Yaron Koren
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

2013-06-20 Thread Yaron Koren
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

2013-06-20 Thread Yaron Koren
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

2013-06-20 Thread Yaron Koren
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

2013-06-09 Thread Yaron Koren
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

2013-05-09 Thread Yaron Koren
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

2013-05-08 Thread Yaron Koren
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

2013-05-08 Thread Yaron Koren
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

2013-05-08 Thread Yaron Koren
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

2013-05-08 Thread Yaron Koren
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

2013-05-08 Thread Yaron Koren
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

2013-05-07 Thread Yaron Koren
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

2013-05-07 Thread Yaron Koren
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

2013-05-06 Thread Yaron Koren
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

2013-05-06 Thread Yaron Koren
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

2013-04-26 Thread Yaron Koren
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

2013-04-21 Thread Yaron Koren
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

2013-04-21 Thread Yaron Koren
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 ?

2013-04-05 Thread Yaron Koren
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 ?

2013-04-04 Thread Yaron Koren
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

2013-03-07 Thread Yaron Koren
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?

2013-02-26 Thread Yaron Koren
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

2013-02-25 Thread Yaron Koren
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

2013-02-25 Thread Yaron Koren
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

2013-02-25 Thread Yaron Koren
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

2013-02-25 Thread Yaron Koren
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


  1   2   3   4   >