Dear Openguides Team,
The category "Digital Communities", which met with great interest and participation in 2004, will be awarded again by Prix Ars Electronica in 2005. As you had been participating last year, we would kindly like to invite you and your team to submit your project "http://openguides.org/" - or a new project - in the category "Digital Communities" of this year's Prix Ars Electronica.
The Digital Communities category of Prix Ars Electronica encompasses digital community projects as well as developments in the field of social software, mobile communications or wireless networks. For a detailed description of the category and about Prix Ars Electronica in general, please see our website:
<http://www.aec.at/en/prix/communities/communities.asp>
Prizes
One Golden Nica with 10,000 Euro and two Awards of Distinction with 5,000 Euro each will be awarded and up to 12 Honorary Mentions made by the jury.
The registration starts January 10, 2005.
The deadline for submissions is March 11, 2005.
Please use
<http://www.aec.at/en/prix/registration/index.asp>
for your submission and to obtain further details.
If you need any further information or help, please do not hesitate to contact us.
Looking forward to your participation!
Sincerely yours,
> Ingrid Fischer-Schreiber
> Prix Ars Electronica 2005
>
> AEC Ars Electronica Center Linz
> Museumsgesellschaft mbH
> Hauptstraße 2
> A-4040 Linz
>
> Tel. ++43.664.8126230
> Fax ++43.732.7272-674
> communities(a)prixars.aec.at
> http://prixars.aec.at
>
>
Dom asked me on IRC yesterday about the code that generates the OGL node
statistics (http://london.openguides.org/statistics/). I've now modulized
it. Please test this:
http://downlode.org/tmp/Openguides-Statistics-1.tar.gz
I've not been able to test it against any databases other than the current
London one (PgSQL), so I have no idea if it will work for others, although
I've tried to write it so that it will. I also only have some very basic
tests for it because I don't know how to write tests for something that
relies on a database.
Cheers,
Earle.
--
Earle Martin
http://downlode.org/http://purl.oclc.org/net/earlemartin/
OpenGuides 0.47 has been released, with minor updates. It is available
from your favourite CPAN mirror, or
http://www.larted.org.uk/~dom/computing/code/openguides/OpenGuides-0.47.tar…
or, indeed, http://www.larted.org.uk/~dom/debian/openguides/.
md5sum:
414f612f0bd5b8542c2230c17309db1c OpenGuides-0.47.tar.gz
(files in this distribution are also signed with cpansign; run
"cpansign -v" to verify.)
Changelog:
Fixed bug with list_all_versions for nodes with only one version.
Extended config changes to examples/reindex.pl (thanks jimbo).
Now require CGI::Wiki 0.62 to fix bug with deleting versions.
Try to ensure that a .htaccess file protecting wiki.conf is installed.
Allow for external URLs for Text Formatting help.
Home node recent changes box now flags new entries.
Made default city and country be blank; specify them if you want them.
Missing PREREQUISITE on Plucene added.
Added CSS id "maincontent" to exclude the navbar and footer. Misc
template tidying including removing old layout tables.
Dominic.
On Tue, Jan 04, 2005 at 08:27:04AM -0500, IvorW wrote:
[could you fix your linewrapping, thanks]
> Just having a braindump on this hot topic.
>
> 1. We should look to improving the user login side of OG/CW. Currently,
> you just go into the "preferences" page and set your ID to whatever you
> want.
>
> If we have a password associated with the ID, this will hopefully
> prevent impersonation and other suchlike abuses. OK so the form may be
> sending the password in clear text
The way I see this working is that a login module can be plugged in, and
if one has logged in somehow, an "authenticated" flag would be set in
edits, such that we can be sure that that user really did submit the
change. That user would then not be presented with the option of
specifying a username.
This is also important for copyright control. It would be far too easy
to claim infringement if submission is entirely anonymous, but this
would of course be up to the individual admin. I wouldn't want to
require login, but maybe the copyright could be assigned to the Guide if
the change was made anonymously? (I am now defining Anonymous to
included non-authenticated usernames).
This is something I've been meaning to look at for absolutely ages;
initially I was thinking of integrating with basic auth, but I think a
decent cookie-based session login will be more useful (suggestions for
modules to use?)
See <https://rt.cpan.org/NoAuth/Bug.html?id=9340>.
> 2. Ideally we want OpenGuides to stay wiki, i.e. allow anonymous
> contributors. But, there's no reason why it needs to be a
> WorldWideWiki, open to Chinese and Russian spammers. We could restrict
> the anonymous login from anywhere but the same country as the guide
> is located in, decoding the country from the IP address (I'm sure
> there's a module or three that does this). Of course we still want
> genuine contributors to add content from abroad - but they can always
> register and log in :).
I think this is going to be more hassle than use. I am less concerned
about spam than impersonation. There's nothing to stop a spammer
registering and logging in, so I see this as a different problem.
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
> -----Original Message-----
> From: openguides-dev-bounces(a)openguides.org
> [mailto:openguides-dev-bounces@openguides.org]On Behalf Of Rev Simon
> Rumble
> Sent: 11 January 2005 10:24
> To: openguides-dev(a)openguides.org
> Subject: [OpenGuides-Dev] Meta metadata?
>
>
> Hi folks.
>
> I've been thinking perhaps OpenGuides needs the ability to have a
> comment or similar for some of its metadata. For example,
> this node is
> about a long-thin object:
> http://engineer.openguides.org/?Manchester_Ship_Canal
My thoughts about this are to have a new type of node called a route.
Such nodes contain a list of (x,y) or (lat,long) pairs tracing a route.
These are joined together by straight lines when displaying on SVG or suchlike.
Another note type with a collection of points is a boundary. This has the
distinction of (i) being cyclic and (ii) having an inside and an outside.
There are also locales, which are collections of points.
</braindump>
>
> This makes it hard to provide coordinates. You could just
> make a point
> of always picking the middle of such an item, but what if you
> wanted to
> pick out the most interesting point?
>
> Consider the Cloaca Maxima in Rome
> (http://en.wikipedia.org/wiki/Cloaca_Maxima -- no node in TE
> yet). It
> runs through the entire city but the most interesting point, from a
> tourist POV, would be its entrance into the Tiber.
>
> So I'm thinking the best way to handle this might be multiple sets of
> coordinates with comments describing their purpose. So for the
> Manchester Ship Canal, you might say "Boat Museum on Manchester Ship
> Canal". Cloaca Maxima you might say "Entrance of Cloaca Maxima into
> Tiber".
One option would be to make each point have a placeholder page, like the
"bus stop" pages. It's debatable whether we need that level of detail, unless
we can automate the process: GPS upload => LWP
Some examples like stations on a line, clearly should have their own page.
My £0.02
Ivor.
Hi folks.
I've been thinking perhaps OpenGuides needs the ability to have a
comment or similar for some of its metadata. For example, this node is
about a long-thin object:
http://engineer.openguides.org/?Manchester_Ship_Canal
This makes it hard to provide coordinates. You could just make a point
of always picking the middle of such an item, but what if you wanted to
pick out the most interesting point?
Consider the Cloaca Maxima in Rome
(http://en.wikipedia.org/wiki/Cloaca_Maxima -- no node in TE yet). It
runs through the entire city but the most interesting point, from a
tourist POV, would be its entrance into the Tiber.
So I'm thinking the best way to handle this might be multiple sets of
coordinates with comments describing their purpose. So for the
Manchester Ship Canal, you might say "Boat Museum on Manchester Ship
Canal". Cloaca Maxima you might say "Entrance of Cloaca Maxima into
Tiber".
Just some idle thoughts.
--
Rev Simon Rumble <simon(a)rumble.net>
www.rumble.net
The Tourist Engineer
Because nerds travel too.
http://engineer.openguides.org/
Trickle-down theory--the less than elegant metaphor that if
one feeds the horse enough oats, some will pass through to
the road for the sparrows.
- J. K. Galbraith
So then.
It looks like we weren't able to sort it out for this month, so let's do the
get-together-and-hack-on-stuff thing this January, 2005. How about the last
weekend of the month (Sat 29/Sun 30)?
BTW - if it's to be at my place, we can accomodate one overnight (or two if
they share a futon!) - first come, first served.
Reply here if you're up for it.
Cheers,
Earle.
--
Earle Martin
http://downlode.org/http://purl.oclc.org/net/earlemartin/
(Quoting the whole thing since most people won't have read the RT thingy.)
On Sun 09 Jan 2005, via RT <comment-OpenGuides(a)rt.cpan.org> wrote:
> This message about OpenGuides was sent to you by DOM via rt.cpan.org
>
> Full context and any attached attachments can be found at:
> <URL: https://rt.cpan.org/Ticket/Display.html?id=6386 >
>
> This is a comment. It is not sent to the Requestor(s):
>
> [IVORW - Sat May 22 17:14:21 2004]:
>
> > [MRAMBERG - Sat May 22 17:01:40 2004]:
> >
> > > Namely, it doesn't support them, so searches for things like
> > > gr�nerl�kka
> > > and gr�nland are moot.
> >
> > I will look at expanding the allowed character set for search strings
> > to take into account internationalization. We need to see if there are
> > issues with Search::InvertedIndex, and make sure that it tokenizes in
> > an i18n way.
>
> Work on this should probably be concentrated on Plucene - see other utf8
> bugs in OpenGuides though.
If we want Unicode searches to work we may need to canonicalise
characters before indexing (and also before searching the indexes of
course) since plenty of characters have more than one Unicode code
point (eg e-acute can be "e-acute" or "e" + "combining acute". I'm
not sure how Perl copes with this issue - anyone?
I was thinking if we're taking the trouble to do this it might also be
a plan to canonicalise further, eg store and search for "e-acute" as
simply "e". Not everyone can type accented characters so either the
data or the search term could be typed as plain "e", and it would be
nice to Do The Right Thing.
I think the right place to do this could be in a new CGI::Wiki::Search::*
that could sit on top of either Search::InvertedIndex or Plucene or even
a simple table in the database.
I'm not working on this at the moment, just occasionally thinking about
the issues.
Kake
Hi all, and a Merry Christmas!
I've been fiddling about with the layout of nottingham.og.o, and have a
few minor issues with the templates I'd like to bring up:
* It appears there is no div that covers all the actual content of a node;
the 'content' div seems to include the navbar as well. Is this
intentional? For what I was hoping to do with the layout, these being
separate divs would probably be really useful -- either for the content
div to stop including the navbar, or for some other div to be created
including the rest of the content div, after the navbar.
* There are two search boxes on every page (navbar, footer). Would it be
easy to add a config option to not have one of them, or just lose the
footer one altogether, or something? I think the one in the navbar is
more immediately visible, so I'd probably prefer to keep that one.
(There's probably also an argument for a special one in home_node.tt
somewhere, for guides which have no navbar on the front page, or
something.)
* The Recent Changes box on the front page looks quite cluttered, and is
bigger than I'd like; one solution to this would be to lose most of it,
just retaining the node names, and maybe the marker proposed in
<http://rt.cpan.org/NoAuth/Bug.html?id=9068>. But, I realise some guides
might want the full version of this box, as it stands. So I suggest a
new config option (yes, I know, another question at install time...)
called something like minimal_recent_changes which can then be used in
the templates to remove the 'fluff' from this box as appropriate.
I'm also not convinced of the point of the "edit this page" link in the
recent changes box, but I assume that's there for a reason I've not
thought of yet!
As another alternative, could the recent changes front page box be made
optional altogether? I assume this would be relatively easy to do, and I
think this is if anything a _more_ useful option than the navbar being
optional.
There's probably other stuff, but it's 3am. I'll follow up to this
message next week, no doubt :-)
Cheers,
James.
--
jkg((-.+)?@(|the\.)earth.li|@(jimbo|wonky)\.org\.uk|03u@cs\.nott\.ac\.uk)
A celebrity is a person who is known for his well-knownness.