Well, I should have clarified why I thought it was a bad idea - the Maps extension is meant to be a very generic extension, that could ideally end up getting used on a lot of wikis, including large ones. That could lead to a lot of confusion over why it contains form-input stuff that seems unrelated to anything else; especially if the documentation says something like, "for questions/bug reports about the form inputs, write to the SMW-users list; for everything else, write to...". It would be a somewhat split-personality extension.

Maybe that's not such a big issue, actually, but that was my reasoning.

-Yaron


On Thu, Jul 16, 2009 at 10:54 AM, Sergey Chernyshev <sergey.chernyshev@gmail.com> wrote:
Actually, third options is OK - it just tells the system that "if SF is enabled, here's additional functionality for it".

This way, it can be SRF + Maps and that's it, right? Do you think there will be other feature in the future that can go into "Semantic Maps" that will go beyond being either part of Maps or SRF? If not, then making it just Maps + SRF might be a good idea - this will definitely will increase distribution. After all, how many "Semantic *" extensions can we have? ;)


Thank you,

        Sergey


--
Sergey Chernyshev
http://www.sergeychernyshev.com/


On Thu, Jul 16, 2009 at 10:47 AM, Yaron Koren <yaron57@gmail.com> wrote:
Let me first comment that I don't think translation/internationalization is an issue either way - translatewiki.net already handles dozens of extensions, and more are always being added; for them to add another extension to the set is trivial, and the translators do an excellent job of taking care of new values, regardless of which extension they came from.

I think perhaps it comes down to a philosophical issue of whether the Semantic Result Formats extension is meant to contain all formats not defined in SMW; or whether it's just a utility extension. The 'calendar' format in SRF already breaks the rules somewhat by defining new parser functions in addition to just a format; but form inputs seem to go beyond that, in that they're not tied in with querying at all.

I should note that there's a third option, which is to move the form inputs into the "Maps" extension: after all, they're just a hook, and people who aren't using SMW/SF can ignore the code. It's probably not a good idea, but I wanted to "throw that out there".

-Yaron


On Thu, Jul 16, 2009 at 9:31 AM, Markus Krötzsch <markus@semantic-mediawiki.org> wrote:
On Donnerstag, 16. Juli 2009, jeroen De Dauw wrote:
> Hey,
>
> After my GSoC project ends, I will remain active in the community, continue
> to support both extensions, and very probably continue on improving them.
> To what extend will ofcourse depend on how much work I'll have at
> university.

Of course. Free software always requires free time. It's already great if
there will be some amount of continued bug fixing and basic maintenance.

>
>
> When released, both extensions will have roughly the same size as they have
> now. Maps is by far the largest, couse it contains the Open Layers API.
> Semantic Maps will be pretty small, and should therefore not form any
> problem when putting the code into SRF. So, as I see it, there are two
> advantages to ading the SM code to SRF: easier to distribute and a bigger
> user base.

+ slightly easier translation/internationalisation since you can use SRF's
message file and don't have to ask Siebrand for a new one ;-).

> And 2 disadvantages: it adds prerequests to the map
> functionallity in SRF (SF & Maps),

This is not a problem. SRF already includes various printers that introduce
further prerequisites. These printers are simply not enabled by default, and
the dependencies are stated in the SRF docs. SRF has a simple way of
configuring which printers to make available by switching them on or off in
LocalSettings.

> and it's less easy to maintain.

Why is that? Every printer in SRF is pretty independent from the others and
has its own subdirectory. So it does not make much of a difference compared to
having a separate directory for one printer. Getting an SVN account for
MediaWiki would be a good idea anyway (if you don't have one already).

(As a bonus, SMW-related SVN code gets its documentation at
http://semantic-mediawiki.org/doc/ ;-)


-- Markus

> IMHO
> this is not very conclusive, and I think that unless there are more
> arguments, it's best to let it be as it is for the moment.
>
> Sergey: Thanks for your suggestions, they are all valid, and I'll implement
> some of them before the first release.
>
> Markus: Thanks for pointing out the links/footnote stuff.
>
> Any more suggestions about Maps and Semantic Maps?
>
>
> Cheers,
> De Dauw '[RTS]BN+VS*' Jeroen
>
>
> Forum: code.bn2vs.com
> Blog: blog.bn2vs.com
>
> Xfire: bn2vs ; Skype: rts.bn.vs
>
> Don't panic. Don't be evil.
> 70 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65!
>
>
>
>
>
> ________________________________
> From: Markus Krötzsch <markus@semantic-mediawiki.org>
> To: semediawiki-devel@lists.sourceforge.net
> Cc: Sergey Chernyshev <sergey.chernyshev@gmail.com>; jeroen De Dauw
> <jeroen_dedauw@yahoo.com> Sent: Wednesday, July 15, 2009 7:49:13 PM
> Subject: Re: [SMW-devel] Maps and Semantic Maps
>
> On Mittwoch, 15. Juli 2009, Sergey Chernyshev wrote:
> > Great news, Jaroen! It's great to see that Mapping becomes more of the
> > generic solution.
>
> +1, having a single (semantic) mapping extension is certainly a worthy
> goal. Including this (the semantic part) into SRF would be useful if the
> required code is not overly large. This would simplify distribution and
> increase the user base, I believe. It would also let you use SRF's
> translatewiki.net account for internationalization.
>
> SRF can also include experimental software, but it is of course desirable
> that somebody is in charge of maintaining each component. Are you
> supporting this code after the GSoC time ends, or is someone else expected
> to take over?
>
> Regards,
>
> Markus
>
>
> P.S. Our public online emails archives do (for security reasons) only show
> plain text versions of emails, but the plain text part of your email
> contains no hints that you included hyperlinks (bad HTML serializer ...).
> It would thus be useful to include URLs explicitly (using "[1]" style
> footnotes for long URLs), so that people browsing mails online can also
> access them. I guess this also applies to subscribers who use email digests
> or text-only email clients.
>
> P.P.S. This said, here are the relevant links:
>
> * Maps: http://www.mediawiki.org/wiki/Extension:Maps
> * Sem' Maps: http://www.mediawiki.org/wiki/Extension:Semantic_Maps
> * Source code: http://ext.bn2vs.com/mw-map-extensionz.zip
> * Updates on Jeroen's blog: http://blog.bn2vs.com/tag/semantic-maps/
>
> > I have a few suggestions though:
> >
> > Maps:
> >
> >    - I think default mapping service should be configurable through the
> >    LocalSettings.php using some global variable.
> >    - Mapping services available to the users should also be configurable
> > as an array of available services.
> >    - it's probably a good idea to remove (or make optional) primary
> >    parameter name - coordinates for display_point and address for
> >    display_address. This way default calls can be abbreviated to
> > *{{#display_point:55.7557860,
> >    37.6176330}}* and *{{#display_address:Moscow, Russia}}* which should
> >    simplify usage significantly.
> >    - Also, for map types, I think Yahoo provides all the types Google
> >    provides and it's worth adding too (it's probably in your plans
> > anyway) - I'll also recommend adding zoombox definition by boundary
> > coordinates or radius around the points - this might be very useful, but
> > harder to implement.
> >
> > Similar suggestions for the Semantic Maps:
> >
> >    - add generic map format that will use default configuration for the
> > Maps extension, e.g.
> >
> >    {{#ask:[[Category:Locations]]|?Has coordinates|format=map}}
> >
> >
> > I'm not sure if moving Semantic Maps as a whole into SRF is necessarily a
> > good idea as it adds some functionality to Semantic Forms and therefore
> > has it as prerequisite - it might be reasonable to move map display code
> > to SRF, but then it's not clear if having forms code separately in
> > another extension is viable.
> >
> > Thank you,
> >
> >         Sergey
> >
> >
> > --
> > Sergey Chernyshev
> > http://www.sergeychernyshev.com/
> >
> > On Wed, Jul 15, 2009 at 10:51 AM, jeroen De Dauw
>
> <jeroen_dedauw@yahoo.com>wrote:
> > > Hey all,
> > >
> > > First of all, let me introduce myself.
> > > I'm Jeroen De Dauw, one of the GSoC students for Wikimedia foundation
> > > this year. I'm working on a map extension for Semantic
> > > MediaWiki<http://semantic-mediawiki.org/wiki/Semantic_MediaWiki>with
> > > Yaron Koren <http://yaronkoren.com/> as mentor.
> > >
> > > During the last 2 months I've been working on this extension (which has
> > > actually split into 2 seperate extensions:
> > > Maps<http://www.mediawiki.org/wiki/Extension:Maps>and Semantic Maps
> > > <http://www.mediawiki.org/wiki/Extension:Semantic_Maps> - click the
> > > links for more info about either extension), and I'm reaching the final
> > > stage before the first release. I'd like to get some feedback on the
> > > code and overall structure of the extensions before I continue, to
> > > ensure no mayor design flaws are present.
> > >
> > > You can get the code for both extensions
> > > here<http://ext.bn2vs.com/mw-map-extensionz.zip>. Note that this code
> > > is still purely dev material, and should NOT be used in a production
> > > environment.
> > >
> > > One of the big questions about the Semantic Maps code is if it should
> > > just be added to Semantic Result Formats or remain separate. What are
> > > your opinions about this?
> > >
> > > Any feedback is welcome. For those who are wondering, if no mayor flaws
> > > are found, both extensions will probably be released in a one or two
> > > week time frame. (I'm posting updates
> > > <http://blog.bn2vs.com/tag/semantic-maps/> on my blog.)
> > > Cheers,
> > > De Dauw '[RTS]BN+VS*' Jeroen
> > >
> > > Forum: code <http://code.bn2vs.com>.bn2vs.com <http://code.bn2vs.com>
> > > Blog: blog.bn2vs.com
> > > Xfire: bn2vs ; Skype: rts.bn.vs
> > >
> > > Don't panic. Don't be evil.
> > > 70 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65!
> > >
> > >
> > >
> > >
> > > -----------------------------------------------------------------------
> > >-- ----- Enter the BlackBerry Developer Challenge
> > > This is your chance to win up to $100,000 in prizes! For a limited
> > > time, vendors submitting new applications to BlackBerry App World(TM)
> > > will have the opportunity to enter the BlackBerry Developer Challenge.
> > > See full prize details at: http://p.sf.net/sfu/Challenge
> > > _______________________________________________
> > > Semediawiki-devel mailing list
> > > Semediawiki-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel


--
Markus Krötzsch
Semantic MediaWiki    http://semantic-mediawiki.org
http://korrekt.org    markus@semantic-mediawiki.org


------------------------------------------------------------------------------

Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel



------------------------------------------------------------------------------

Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel