"JP" == Jonathan Phillips jon@protofunk.org writes:
JP> Maybe a novel idea would be to make separate project on JP> sourceforge that is svg clipart. Like svg-clipart.sf.net would JP> be great.
JP> The benefits would be open source designing of symbols, maps, JP> etc for the SVG-compliant community.
JP> It might also be nice to push the artwork developed via JP> different SVG apps to a standard, well defined place that JP> might promote interoperability and compliance of all,or many JP> :) ofthe different SVG drawing programs.
JP> It would be totally cool to use CVS to design with and allow JP> ppl. from all over the world to work on designs.
JP> Thoughts? (I hope I haven't just gotten a little too utopian)
I think you're totally utopian, which is great!
What I wonder is whether a Wiki format might not work better for collaboration than CVS. CVS requires setting up user permissions for lots of people, and it can be a hassle. Wikis lower the bar for participation considerably.
The Wikimedia Foundation has a number of Wiki-related projects going on. There's a big demand for images from Wikipedia and the other related projects. I've started a proposal on the Meta-Wikipedia Wiki about doing a Wikiclip clip-art Wiki site:
http://meta.wikipedia.org/wiki/Wikiclip
It'd be interesting to see how this could develop.
~ESP
On Sun, 2003-12-07 at 21:00, Evan Prodromou wrote:
What I wonder is whether a Wiki format might not work better for collaboration than CVS. CVS requires setting up user permissions for lots of people, and it can be a hassle. Wikis lower the bar for participation considerably.
But doesn't it also lower the bar for pranks and such--say, person A adds a piece of clipart that person B doesn't like, so B modifies it surreptitiously? CVS would log things like that.
Hello!
It may even work for things like clipart... For software project, you want to keep it compilable and reduce enthropy at all costs. Lot of such is not issue in case of collaborative clipart project.
Best wishes, Lauris Kaplinski
John Stracke kirjutas E, 08.12.2003 kell 13:48:
On Sun, 2003-12-07 at 21:00, Evan Prodromou wrote:
What I wonder is whether a Wiki format might not work better for collaboration than CVS. CVS requires setting up user permissions for lots of people, and it can be a hassle. Wikis lower the bar for participation considerably.But doesn't it also lower the bar for pranks and such--say, person A adds a piece of clipart that person B doesn't like, so B modifies it surreptitiously? CVS would log things like that.
"JS" == John Stracke francis+dated+1086436124.b8e8db@thibault.org writes:
Me> Wikis lower the bar for participation considerably.
JS> But doesn't it also lower the bar for pranks and such--say, JS> person A adds a piece of clipart that person B doesn't like, JS> so B modifies it surreptitiously? CVS would log things like JS> that.
So, a couple of things about this:
* Yes, it lowers the bar for abuse, too. But experience with Wikis like Wikipedia has shown that the good tends to overwhelm the bad. If you have a community of people dedicated to the idea of the project, they can "self-police" the wiki. After all, A can always revert B's changes. Or C can, or D or E or F.
I think it works because, since it's so easy to change stuff, B will get bored with abuse pretty quickly. Also, A, C, D, E, and F are more committed usually to the project, than B is to causing mayhem.
* There are a number of features in the MediaWiki software that runs most of the Wikimedia projects (and Wikitravel, by the way) to track edits and quickly detect abuse. It's hard to do things "surreptitiously".
* Recent changes * Page histories * User contributions lists * New pages lists * Upload, delete, protect
* Most of the features that could cause permanent damage, on MediaWiki sites, are reserved for special administrator users. So, for example, most people can't delete an image, a page, or whatever. They can take out all the content, but they can't delete the marker, or the history, or whatever.
There's a few pages that go over how Wikis actually can work for sharing important data. On Wikipedia, there's the replies to common objections:
http://www.wikipedia.org/wiki/Wikipedia:Replies_to_common_objections
On Meatball Wiki (a Wiki about how Wikis and other online communities work), there's a page on "Soft Security":
http://www.usemod.com/cgi-bin/mb.pl?SoftSecurity
...and one on limiting damage:
http://www.usemod.com/cgi-bin/mb.pl?LimitDamage
Anyways, lots of blather about Wiki, which is probably off-topic for both sodipodi-l and wikipedia-l. Sorry to both communities for excessive cross-posts, but I think this is an interesting topic that should probly be looked into.
~ESP
John Stracke wrote:
Evan Prodromou wrote:
What I wonder is whether a Wiki format might not work better for collaboration than CVS. CVS requires setting up user permissions for lots of people, and it can be a hassle. Wikis lower the bar for participation considerably.
But doesn't it also lower the bar for pranks and such--say, person A adds a piece of clipart that person B doesn't like, so B modifies it surreptitiously? CVS would log things like that.
And RecentChanges logs things like that on a wiki.
However, the MediaWiki software, IIRC, had some failings in this respect when it comes to images -- people were able to overwrite uploaded files (which is how MediaWiki treats images) in a way that destroyed information. Has that all been fixed?
-- Toby
On Dec 8, 2003, at 16:25, Toby Bartels wrote:
Evan Prodromou wrote:
What I wonder is whether a Wiki format might not work better for collaboration than CVS.
However, the MediaWiki software, IIRC, had some failings in this respect when it comes to images -- people were able to overwrite uploaded files (which is how MediaWiki treats images) in a way that destroyed information. Has that all been fixed?
In MediaWiki when you upload a new file with the same name as an existing file, the old version is archived and remains accessible. It can be viewed, saved locally and reuploaded with a new name, or reverted in-place. _Deleting_ an image revision would do so permanently, but this is now a restricted admin action.
SVG is an interesting case though; being XML-based it would be possible to provide SVG files in human-readable -- and even human-editable -- source form. That's something we don't currently provide for, but it would be possible to provide for a file upload form that stores data into a wiki page.
OddMuse's file upload feature works like this, I believe. (http://www.oddmuse.org/)
Also hypothetically a plugin- or java-based editor app could be launched directly from the page, but that's outside the scope of this stuff...
-- brion vibber (brion @ pobox.com)
On Mon, 8 Dec 2003, Brion Vibber wrote:
In MediaWiki when you upload a new file with the same name as an existing file, the old version is archived and remains accessible. It can be viewed, saved locally and reuploaded with a new name, or reverted in-place. _Deleting_ an image revision would do so permanently, but this is now a restricted admin action.
I'd imagine this approach would nicely satisfy the principle requirements of such a system.
SVG is an interesting case though; being XML-based it would be possible to provide SVG files in human-readable -- and even human-editable -- source form. That's something we don't currently provide for, but it would be possible to provide for a file upload form that stores data into a wiki page.
While I don't know many people that habitually hand-edit SVG files, I could imagine something akin to this might be useful for templatified graphics, such as street signs, language translatable signs, etc.
OddMuse's file upload feature works like this, I believe. (http://www.oddmuse.org/)
Also hypothetically a plugin- or java-based editor app could be launched directly from the page, but that's outside the scope of this stuff...
You should check this out:
http://www.xml.com/pub/a/2003/11/19/svgwiki.html
Bryce
"BH" == Bryce Harrington bryce@osdl.org writes:
BH> http://www.xml.com/pub/a/2003/11/19/svgwiki.html
That's about the coolest thing I've seen all week.
~ESP
-- Evan Prodromou evan@wikitravel.org Wikitravel - http://www.wikitravel.org/ The free, complete, up-to-date and reliable world-wide travel guide
Brion Vibber wrote in part:
Toby Bartels wrote:
However, the MediaWiki software, IIRC, had some failings in this respect when it comes to images -- people were able to overwrite uploaded files (which is how MediaWiki treats images) in a way that destroyed information. Has that all been fixed?
In MediaWiki when you upload a new file with the same name as an existing file, the old version is archived and remains accessible. It can be viewed, saved locally and reuploaded with a new name, or reverted in-place. _Deleting_ an image revision would do so permanently, but this is now a restricted admin action.
OK, this is what I was thinking of, and it was fixed. So MediaWiki should work fine for showing images to one another, and for writing things about them in wiki pages. But if you want to modify the images' /sources/ then you want something then lets you view diffs of the sources -- which may be SVGwiki or something else, depending on what kind of images you use!
-- Toby (from Wikipedia), done talking
"TB" == Toby Bartels toby+wikipedia@math.ucr.edu writes:
TB> OK, this is what I was thinking of, and it was fixed. So TB> MediaWiki should work fine for showing images to one another, TB> and for writing things about them in wiki pages. But if you TB> want to modify the images' /sources/ then you want something TB> then lets you view diffs of the sources -- which may be TB> SVGwiki or something else, depending on what kind of images TB> you use!
You don't need to view diffs to modify the source files. You just need to download the files, edit them, and upload the new versions. No, it doesn't happen in the browser, but that's probably OK -- I don't think a browser-based image editor could ever have the kind of features that (say) Sodipodi has.
Diffing images is kinda hard. For vector image formats it's a little easier, and for stuff like SVG it might actually be practical, but for most purposes it's _extremely_ difficult to automatically detect the "difference" between two images. I doubt it would be worth the effort.
~ESP
Evan Prodromou wrote in part:
You don't need to view diffs to modify the source files.
Not at all. Losing the diffs just means losing one nice feature of the Recentchanges avaiable with most wiki software (including MediaWiki).
Diffing images is kinda hard. For vector image formats it's a little easier, and for stuff like SVG it might actually be practical, but for most purposes it's _extremely_ difficult to automatically detect the "difference" between two images. I doubt it would be worth the effort.
I was hoping that for SVG it would be practical and even useful, and if one is using SVG images, then maybe svgwiki already does this. But for PNGs and JPEGs? Ha! No, not worth the effort.
-- Toby
"TB" == Toby Bartels toby+wikipedia@math.ucr.edu writes:
TB> I was hoping that for SVG it would be practical and even TB> useful, and if one is using SVG images, then maybe svgwiki TB> already does this.
Ah! That's possibly the source of the misunderstanding. The existing "SVGWiki" is an (all-text) wiki _about_ SVG (the standard, how to use it, etc.).
http://www.protocol7.com/svg-wiki/
This (single-page) whiteboarding demonstration:
http://purplewiki.blueoxen.net/cgi-bin/wiki.pl?WikiWhiteboard
...uses SVG and Wiki in a very interesting way, but it's far from an SVG-based wiki. AFAIK, there is no SVG-based wiki around.
~ESP
On Wed, 10 Dec 2003, Toby Bartels wrote:
Diffing images is kinda hard. For vector image formats it's a little easier, and for stuff like SVG it might actually be practical, but for most purposes it's _extremely_ difficult to automatically detect the "difference" between two images. I doubt it would be worth the effort.
I was hoping that for SVG it would be practical and even useful, and if one is using SVG images, then maybe svgwiki already does this. But for PNGs and JPEGs? Ha! No, not worth the effort.
It is possible to diff bitmap images, as this is done with motion detection in security cameras. For example, I took a testsuite of SVG's from W3C and ran them through Sodipodi, then used the image differ to find where Sodipodi differed from the spec, using a tool called motiontrack: http://freshmeat.net/projects/motiontrack/
Bryce
wikipedia-l@lists.wikimedia.org