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.chernys...@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 <yaro...@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 <
>> mar...@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 <mar...@semantic-mediawiki.org>
>>> > To: semediawiki-devel@lists.sourceforge.net
>>> > Cc: Sergey Chernyshev <sergey.chernys...@gmail.com>; jeroen De Dauw
>>> > <jeroen_ded...@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_ded...@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 mar...@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
>>
>>
>
------------------------------------------------------------------------------
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
