Hello. As people may have noticed, I've been doing some OpenGuides hacking recently. I've got a few ideas for more things I might like to do, but I've been holding off slightly since (a) I don't understand how commit access etc works these days, and (b) I have this sort of vision in my head of loads of you all beavering away on stuff, and I didn't want to step on toes or clash with someone else's work.
However, I'm not sure how true (b) is, so I was wondering, if people have a moment, could they write a quick update for the mailing list on what (if anything) they're working on at the moment? I'm sure this would be of interest to people other than me, as well.
(And if _nobody_ is currently working on anything, this may well prove an incentive for me to get my finger out!)
Kake
Kake L Pugh wrote:
Hello. As people may have noticed, I've been doing some OpenGuides hacking recently.
Yay hay! Excellent! Kake++
I've got a few ideas for more things I might like to do, but I've been holding off slightly since (a) I don't understand how commit access etc works these days, and (b) I have this sort of vision in my head of loads of you all beavering away on stuff, and I didn't want to step on toes or clash with someone else's work.
The theory is that we coordinate this through the dev wiki, with people's home pages carrying their personal todo lists. Granted I haven't updated mine for a long while, but I'm going through lots of personal stuff at the moment.
Do you have acces to trac? If not, prod Dom with an htpasswd.
However, I'm not sure how true (b) is, so I was wondering, if people have a moment, could they write a quick update for the mailing list on what (if anything) they're working on at the moment? I'm sure this would be of interest to people other than me, as well.
Ideally we _should_ all be sharing our code changes with the rest of the OpenGuides community. Unfortunately, there are some extremely forked code bases out in the big wide world, which is making upgrades difficult for some.
I'm a firm believer in a single code base and repository. I'm also a firm believer that the dev wiki is the place to put informtion about what we are working on. I will update my personal todo list before the end of the weekend. I encourage others on list who have accounts on trac to do likewise.
(And if _nobody_ is currently working on anything, this may well prove an incentive for me to get my finger out!)
Probably not the case, but I'll certainly be (re)moving items of mine which say they are in progress, which aren't. Anyway, I don't think there's a hive of activity on OG and Wiki::Toolkit right now, so as far as I'm concerned, go for it.
We had a flurry of activity in December, with the Oxford hackfest and immediatey afterwards.
It may be worth touching base with Dom about any major changes or releases in the pipeline.
Welcome back, we missed you.
Ivor,
On Sat, Mar 03, 2007 at 05:10:19PM +0000, Kake L Pugh wrote:
However, I'm not sure how true (b) is, so I was wondering, if people have a moment, could they write a quick update for the mailing list on what (if anything) they're working on at the moment? I'm sure this would be of interest to people other than me, as well.
I have plans to scratch the OpenID itch. My wife has me working on a hacked version of the guide to help our local neighborhood with planning events, and what not. But her ideas all involve Users and Events. I was planning on using OpenID and some Wiki::Toolkit plugins to create real User nodes. It's been on my radar for a while, but the itch only recently came up.
I'm in the midst of changing jobs and some other projects have pushed themselves forward, so I've no clue how much time I'll be able to devote in the next two weeks or so. I'm not sure what your idea of "currently".
-Chris
On Sat 03 Mar 2007, Chris Prather chris@prather.org wrote:
I have plans to scratch the OpenID itch. My wife has me working on a hacked version of the guide to help our local neighborhood with planning events, and what not. But her ideas all involve Users and Events. I was planning on using OpenID and some Wiki::Toolkit plugins to create real User nodes. It's been on my radar for a while, but the itch only recently came up.
Bob's been looking at OpenID as well - he said he tried something but it didn't compile. Not sure what - and he's out at the moment so I can't ask him, but he can explain for himself when he reads this :)
Kake
On Sat 03 Mar 2007, IvorW ivorw-openguides@xemaps.com wrote:
The theory is that we coordinate this through the dev wiki, with people's home pages carrying their personal todo lists. Granted I haven't updated mine for a long while, but I'm going through lots of personal stuff at the moment.
I understand that some people prefer doing things on wikis, but I was rather hoping we could get a bit of a discussion going on the list over what people are interested in, whether anyone's halfway through some code and would like some input to get them over a hurdle, whether someone's longing for a feature that someone else has had some useful thoughts about, etc.
I kind of miss the big brain dumps Jo used to post to the list.
Ideally we _should_ all be sharing our code changes with the rest of the OpenGuides community. Unfortunately, there are some extremely forked code bases out in the big wide world, which is making upgrades difficult for some.
It might be worth starting a discussion on why people needed to fork in the first place. Was it primarily because you expected to get around to packaging up your changes and sending in patches, but didn't? Or because your patches were difficult to integrate into the distro for some reason? Or because you wanted to do something that wasn't appropriate for the main distro, but couldn't work out how to do it separately and integrate it into your Guide unobtrusively? Or something else?
I'm not thinking along the lines of assigning blame here, more along the lines of trying to dissect the problem in order to work out what can be done to solve it.
Welcome back, we missed you.
Thanks!
Kake
On Sun, Mar 04, 2007 at 03:29:01PM +0000, Kake L Pugh wrote:
On Sat 03 Mar 2007, IvorW ivorw-openguides@xemaps.com wrote:
Ideally we _should_ all be sharing our code changes with the rest of the OpenGuides community. Unfortunately, there are some extremely forked code bases out in the big wide world, which is making upgrades difficult for some.
It might be worth starting a discussion on why people needed to fork in the first place.
I have some patches to which each of these apply.
Was it primarily because you expected to get around to packaging up your changes and sending in patches, but didn't?
* memcached integration falls into this category.
Or because you wanted to do something that wasn't appropriate for the main distro, but couldn't work out how to do it separately and integrate it into your Guide unobtrusively?
* Geocoder.us lookups fall into this category. * My particular brand of spam catching falls into this category. "couldn't" is relative -- I might have been able to, but didn't have the time to.
Or because your patches were difficult to integrate into the distro for some reason?
* http://dev.openguides.org/ticket/11 -- posted a patch with a 'running start', never got looked at with feedback on how I should change it.
My problem is I know very little perl, so I don't trust what I write, and I don't get a feeling that I'm getting a lot of feedback on what I should be doing to get code back to trunk. I have at least a couple outstanding minor patches in the OG trac that I don't know the status of or what I should do with.
Regards,
On Sun 04 Mar 2007, Kake L Pugh kake@earth.li wrote:
I was rather hoping we could get a bit of a discussion going on the list over what people are interested in, whether anyone's halfway through some code and would like some input to get them over a hurdle, whether someone's longing for a feature that someone else has had some useful thoughts about, etc.
One thing I'm thinking about at the moment is our handling of the X/Y/lat/log data; this is fuelled by my playing with GPS. (This is a bit UK-specific, I think, sorry.)
First of all, I'm a little reluctant sometimes to use OpenGuides as the canonical repository for my hand-collected geodata, since Geography::NationalGrid::GB, which we use for internal conversion, is in disagreement with the conversions produced by the conversion tool on the Ordnance Survey site[0]. (Looking at the PDF guide I downloaded from there, I _think_ the problem is that while Geo::NatGrid::GB does part of the lat/log->X/Y conversion, it doesn't bundle the datafiles that are necessary to add the final corrections - is that right?)
[0] http://gps.ordnancesurvey.co.uk/etrs89geo_natgrid.asp
So - if a Guide accepts data as X/Y coords, then when I put in the OSGB data generated by my GPS unit, the Guide will inaccurately convert those coords to lat/long, and spit out inaccurate lat/long when someone asks for the data. If it accepts data as lat/long coords, then it will spit out inaccurate X/Y when someone asks for the data.
I'm not sure what the answer to this is. There was a discussion on the london.pm mailing list recently, in which people spoke lots about releasing code, but nobody actually did.
I'm vaguely wondering if the OS would be happy with a module that let people query their webservice automatically, and if so, if it would be easy to make the internal coord conversion of OpenGuides more "pluggable", so people could choose to use the webservice module instead, if they cared more about accuracy than about being able to keep going in the face of the OS website not responding.
Another possibility would be to let people have the option of entering _both_ lat/long and X/Y, and treating them as effectively independent sets of data. If someone chose not to enter both, the internal conversion could still take place, but the data would be flagged (in the database and the output) as auto-converted.
What do people think?
Kake
On Sun, Mar 04, 2007 at 03:29:01PM +0000, Kake L Pugh wrote:
It might be worth starting a discussion on why people needed to fork in the first place.
On Sun 04 Mar 2007, Christopher Schmidt crschmidt@crschmidt.net wrote:
I have some patches to which each of these apply.
Thanks for the reply! Did I miss any reasons? I wasn't expecting to be able to cover the entire range of reasons, it was just a list of possible things, off the top of my head.
(I don't want to address any of your specific points until Dom's had a chance to reply, since he's in charge now, not me.)
Kake
Kake L Pugh wrote:
[0] http://gps.ordnancesurvey.co.uk/etrs89geo_natgrid.asp
So - if a Guide accepts data as X/Y coords, then when I put in the OSGB data generated by my GPS unit, the Guide will inaccurately convert those coords to lat/long, and spit out inaccurate lat/long when someone asks for the data. If it accepts data as lat/long coords, then it will spit out inaccurate X/Y when someone asks for the data.
I'm not sure what the answer to this is. There was a discussion on the london.pm mailing list recently, in which people spoke lots about releasing code, but nobody actually did.
I started that thread. I'll happily mail you the code that I used for this if you want it, but it's just a very ploddy implementation of the textual algorithm from the the ordnance survey site pdf you have, which assumes the lookup tables have been uploaded to mysql before querying them.
I've only done it in one direction (northing/easting-> lat/long) but there is also a description of the reverse algorithm in the same document. About 30 lines of code or so.
The problems wouldn't be code, they would be in distributing the lookup tables. Maybe it would be enough just to point people to the os site for the data. But Dirk on london.pm kind of implied he had a way to get the same level of accuracy without the tables, it might be worth asking him.
Graham
I'm vaguely wondering if the OS would be happy with a module that let people query their webservice automatically, and if so, if it would be easy to make the internal coord conversion of OpenGuides more "pluggable", so people could choose to use the webservice module instead, if they cared more about accuracy than about being able to keep going in the face of the OS website not responding.
Another possibility would be to let people have the option of entering _both_ lat/long and X/Y, and treating them as effectively independent sets of data. If someone chose not to enter both, the internal conversion could still take place, but the data would be flagged (in the database and the output) as auto-converted.
What do people think?
Kake
My dev wiki page now has progress indicators, as per my previous email.
On Sun, 4 Mar 2007, Kake L Pugh wrote:
One thing I'm thinking about at the moment is our handling of the X/Y/lat/log data; this is fuelled by my playing with GPS. (This is a bit UK-specific, I think, sorry.)
I think we should have this fixed in the latest SVN. It has code (using MySociety's Geo::HelmertTransform) which is able to do the switch between WGS84 and OSGB36, which then allows your eastings and northings to come out correct.
I think you just need to install Geo::HelmertTransform, set geo_handler to 1, and force_wgs84 to 0
Nick
On Sun, 4 Mar 2007, Kake L Pugh wrote:
Bob's been looking at OpenID as well - he said he tried something but it didn't compile. Not sure what - and he's out at the moment so I can't ask him, but he can explain for himself when he reads this :)
I was looking at restricting POST access from within apache using ModAuthOpenID ( http://www.butterfat.net/wiki/Projects/ModAuthOpenID )
since most people we want to edit the guide get opendi for free with Livejournal. however given my OS of choice compiling the the prereqs didnt work. godamm linux and c++ weenies.
Ideally id liek the openid stuff intergrated into wiki::toolkit so it could determine editng and indeed admin rights.
On Sun 04 Mar 2007, Nick Burch openguides@gagravarr.org wrote:
I think we should have this fixed in the latest SVN. It has code (using MySociety's Geo::HelmertTransform) which is able to do the switch between WGS84 and OSGB36, which then allows your eastings and northings to come out correct.
I think you just need to install Geo::HelmertTransform, set geo_handler to 1, and force_wgs84 to 0
I don't think this is quite it. As I understand it, this is what's happening:
I'm putting OSGB eastings/northings into the Guide edit form (either direct from my GPS or converted on the OS website). The Guide is running Geography::NationalGrid::GB on it, to convert these into OSGB lat/long. This gets stored in the database.
For Google maps display, the stored OSGB lat/long are converted using Helmert transforms into WGS84 lat/long, and passed to Google to do its thing.
The data in the database, and displayed on the page in RDF, are still in OSGB lat/long, though. This is a problem because (a) the RDF is claiming that these are WGS84 (xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#") and (b) people will assume the lat/long displayed on the page are WGS84, because (as far as I know) nobody actually uses OSGB lat/long.
We could use Geo::HelmertTransform in other places in the code in order to make the database lat/long into WGS84 - but this is still only an approximation. I'd really like the option to configure my Guide to use something more exact (the OS reference implementation), since my GPS readings are already inexact.
(I wouldn't have any problem rewriting everything in my Guide in order to correct the lat/long data already in the database, BTW.)
(Alternatively, Graham's code uses the datafiles from the reference implementation to change OSGB x/y into WGS84 x/y, so something along these lines could be plugged in before we run Geography::NationalGrid::GB, but this would involve someone writing a (admittedly of wider use) module that bundled the datafiles.)
Does that make sense? Have I got anything wrong?
Kake
On Sun 04 Mar 2007, Kake L Pugh kake@earth.li wrote:
The data in the database, and displayed on the page in RDF, are still
That should be:
...displayed on the page _and_ in RDF...
Sorry.
Kake
On Sun, Mar 04, 2007 at 08:21:02PM +0000, Bob Walker wrote:
On Sun, 4 Mar 2007, Kake L Pugh wrote:
Bob's been looking at OpenID as well - he said he tried something but it didn't compile. Not sure what - and he's out at the moment so I can't ask him, but he can explain for himself when he reads this :)
I was looking at restricting POST access from within apache using ModAuthOpenID ( http://www.butterfat.net/wiki/Projects/ModAuthOpenID )
FWIW, I've already seen spammers setting up free, throwaway OpenID accounts. If you're going to go this route, you might want to restrict to "trusted' openid providers, such as LJ.
On Sun, 4 Mar 2007, jesse wrote:
FWIW, I've already seen spammers setting up free, throwaway OpenID accounts. If you're going to go this route, you might want to restrict to "trusted' openid providers, such as LJ.
indeed. that was the plan. althogh admiitedly its not outside the realms of possibility that spammers can set up spam LJs.
On Sun, 4 Mar 2007, Kake L Pugh wrote:
On Sun 04 Mar 2007, Kake L Pugh kake@earth.li wrote:
The data in the database, and displayed on the page in RDF, are still
That should be:
...displayed on the page _and_ in RDF...
You might just need to tweak the templates, so that when displaying lat and long, they always use the WGS ones (which ought to exported to the page).
Nick
On Sun 04 Mar 2007, Nick Burch openguides@gagravarr.org wrote:
You might just need to tweak the templates, so that when displaying lat and long, they always use the WGS ones (which ought to exported to the page).
Thanks - that'll work as a hack around the data-on-page problem; and a similar hack could be put into OpenGuides::RDF to sort out the RDF thing.
There's still the problem of the lat/long being wrong in the database though, and I think this is important. Part of the reason I based CGI::Wiki on a database backend in the first place was that I always had in mind that people would be able to use SQL to get data out in unforeseen ways. Historical reasons aren't really justifications for doing anything, of course, but I think I've showed recently (e.g. the search thingy I posted to the list) that direct database access is a real possibility, and really useful.
(Also, the main reason the conversion isn't in there already is that when we wrote that part I didn't really understand about ellipsoids, and so didn't realise it was necessary.)
The other thing, which I only just realised, is that the "advanced search" page lets you search for things within a certain distance of a given lat/long. Nobody's going to put OSGB lat/long in here - WGS84 is much more likely. I realise that the error in the results is only going to be at most 20m, but it still niggles.
Basically, I think it would be better to store data that _doesn't_ need munging, rather than try to catch every place where it might be output, and munge it there before we output it.
But I might be being too fussy, and if people think I am then please do say so.
Kake
On 4 Mar 2007, at 20:37, Bob Walker wrote:
On Sun, 4 Mar 2007, jesse wrote:
FWIW, I've already seen spammers setting up free, throwaway OpenID accounts. If you're going to go this route, you might want to restrict to "trusted' openid providers, such as LJ.
indeed. that was the plan. althogh admiitedly its not outside the realms of possibility that spammers can set up spam LJs.
Using OpenID is great.
Using it because it you think it's anti-spam is totally misunderstanding what it is, sorry.
Enabling it, but then whitelisting it is even worse, it's a horrible hack that doesn't even work (as Bob noted).
In conclusion, integrate OpenID please, but don't prevent anyone from using their OpenID, because that is completely against the whole idea of a distributed ID system. Also, please try to understand that any way this is done, it will not prevent spam.
Regards,
Daniel Alexander Smith
On Mon, Mar 05, 2007 at 01:04:39AM +0000, Daniel Alexander Smith wrote:
In conclusion, integrate OpenID please, but don't prevent anyone from using their OpenID, because that is completely against the whole idea of a distributed ID system. Also, please try to understand that any way this is done, it will not prevent spam.
I run a trac instance that was getting tons of spam. I set up a default username/password on the system -- and put the username and password in the 'AuthName'.
The spam stopped. Technically, the solution was no better -- but the additional cost did change the amount of spam I got. OpenID may have the same affect.
It may not prevent spam, but it may help limit it.
Regards,
On Sun, 4 Mar 2007, Kake L Pugh wrote:
There's still the problem of the lat/long being wrong in the database though, and I think this is important. Part of the reason I based CGI::Wiki on a database backend in the first place was that I always had in mind that people would be able to use SQL to get data out in unforeseen ways. Historical reasons aren't really justifications for doing anything, of course, but I think I've showed recently (e.g. the search thingy I posted to the list) that direct database access is a real possibility, and really useful.
Maybe we should do the conversion to wgs84 at page save time, put the un-converted lat/long into a new field (eg local_lat, local_long), and make the (current) lat/long fields hold the wgs84 one?
That way, most things that want lat/long will get the wgs84 one (which they probably expect), we have the local one to hand if needed, and we only need to do the conversion on page save, not each page view.
Nick
On Mon 05 Mar 2007, Nick Burch openguides@gagravarr.org wrote:
Maybe we should do the conversion to wgs84 at page save time, put the un-converted lat/long into a new field (eg local_lat, local_long), and make the (current) lat/long fields hold the wgs84 one?
Sounds good to me. And then the presence/absence of local_lat, local_long data works as a marker for whether the lat/long fields are WGS84, if anyone feels the need to find that out.
Shall I do that, then? Or does someone else want to?
Kake
On Sat, Mar 03, 2007 at 05:10:19PM +0000, Kake L Pugh wrote:
Hello. As people may have noticed, I've been doing some OpenGuides hacking recently. I've got a few ideas for more things I might like to do, but I've been holding off slightly since (a) I don't understand how commit access etc works these days, and (b) I have this sort of vision in my head of loads of you all beavering away on stuff, and I didn't want to step on toes or clash with someone else's work.
Full reply to this thread to follow, but welcome back, Kake (who now has commit access)!
Dominic.
On Sat, Mar 03, 2007 at 05:10:19PM +0000, Kake L Pugh wrote:
Hello. As people may have noticed, I've been doing some OpenGuides hacking recently. I've got a few ideas for more things I might like to do, but I've been holding off slightly since (a) I don't understand how commit access etc works these days, and (b) I have this sort of vision in my head of loads of you all beavering away on stuff, and I didn't want to step on toes or clash with someone else's work.
However, I'm not sure how true (b) is, so I was wondering, if people have a moment, could they write a quick update for the mailing list on what (if anything) they're working on at the moment? I'm sure this would be of interest to people other than me, as well.
(And if _nobody_ is currently working on anything, this may well prove an incentive for me to get my finger out!)
I'll dig into other bits of this thread, but for my part I haven't really touched OpenGuides since the last release. I blame at least some of this on all the hectic activity that seems to be clustering up in advance of my wedding, so will try and get myself organised for some more work on OpenGuides after that.
(Belated) welcome back, Kake!
Dominic.
On Mon, Mar 05, 2007 at 04:32:23PM +0000, Kake L Pugh wrote:
On Mon 05 Mar 2007, Nick Burch openguides@gagravarr.org wrote:
Maybe we should do the conversion to wgs84 at page save time, put the un-converted lat/long into a new field (eg local_lat, local_long), and make the (current) lat/long fields hold the wgs84 one?
Sounds good to me. And then the presence/absence of local_lat, local_long data works as a marker for whether the lat/long fields are WGS84, if anyone feels the need to find that out.
Shall I do that, then? Or does someone else want to?
+1 from that.
If being really organised you could make this a ticket in trac and put your name against it :)
http://dev.openguides.org/newticket
Dominic.
On Sun, Mar 04, 2007 at 08:23:10PM +0000, Kake L Pugh wrote:
We could use Geo::HelmertTransform in other places in the code in order to make the database lat/long into WGS84 - but this is still only an approximation. I'd really like the option to configure my Guide to use something more exact (the OS reference implementation), since my GPS readings are already inexact.
Could you be more specific about the OS reference implementation? As I understood it the Helmert transform we're currently using is more than accurate enough for the OpenGuides application.
Cheers,
Dominic.
On Fri 09 Mar 2007, Dominic Hargreaves dom@earth.li wrote:
Could you be more specific about the OS reference implementation?
(Lots) more info here; download the zip file for a PDF and the datafiles: http://www.ordnancesurvey.co.uk/oswebsite/gps/osnetfreeservices/furtherinfo/...
Online converter here: http://gps.ordnancesurvey.co.uk/etrs89geo_natgrid.asp
As I understood it the Helmert transform we're currently using is more than accurate enough for the OpenGuides application.
It will do, yes. I was mainly concerned about the RDF output, i.e. other people using our geodata for their own purposes, but I don't know if anyone actually _is_, so there's probably no point in putting in effort for extra accuracy at this point.
Kake
Hi folks,
As I understood it the Helmert transform we're currently using is more than accurate enough for the OpenGuides application.
It will do, yes. I was mainly concerned about the RDF output, i.e. other people using our geodata for their own purposes, but I don't know if anyone actually _is_, so there's probably no point in putting in effort for extra accuracy at this point.
FWIW I'm planning to make use of the OG geodata in RDF sometime pretty soon, but will only need as much precision as the Guides need, i.e. just enough to show a flag in *roughly* the right location on a Gmap. Not sure if this has any bearing on the situation.
Cheers,
Tom.
On Fri 09 Mar 2007, Tom Heath tom.heath@gmail.com wrote:
FWIW I'm planning to make use of the OG geodata in RDF sometime pretty soon, but will only need as much precision as the Guides need, i.e. just enough to show a flag in *roughly* the right location on a Gmap. Not sure if this has any bearing on the situation.
Ooh, cool. What are you going to be doing with it?
Kake
Hi Kake,
In a nutshell I'd like to use the OG sites as a source of geodata for items reviewed at Revyu.com.
You may have picked up from previous posts on this list that I'm working on Revyu.com [1] at the moment. People can use the site to review any things they want, some of which will be SpatialThings that could sensibly use lat/lon data (pubs, restaurants, museums). However, to keep the Revyu.com interface generic and avoid it becoming some big silo (which would not be very semantic web-by), I'm keen to piggy back on other data sources for this info, rather than add a "add lat/lon to this thing" form into Revyu.
Open Guides could be an ideal source (issues of global coverage aside), as long as I can come up with a reasonable heuristic for matching reviewed things in Revyu with their entry in a Guide. Assuming I can, then I can retrieve the lat/lon data from the OG entry RDF, show a nice Gmap on the relevant Revyu page, and also add owl:sameAs statements to the Revyu RDF output linking Revyu entries with OG entries. This would add nicely to the Linking Open Data project at [2].
Will let you know when/how it goes. Comments welcomed :)
Tom.
[1] http://revyu.com/ [2] http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData
On 11/03/07, Kake L Pugh kake@earth.li wrote:
On Fri 09 Mar 2007, Tom Heath tom.heath@gmail.com wrote:
FWIW I'm planning to make use of the OG geodata in RDF sometime pretty soon, but will only need as much precision as the Guides need, i.e. just enough to show a flag in *roughly* the right location on a Gmap. Not sure if this has any bearing on the situation.
Ooh, cool. What are you going to be doing with it?
Kake
-- OpenGuides-Dev mailing list - OpenGuides-Dev@lists.openguides.org http://lists.openguides.org/cgi-bin/mailman/listinfo/openguides-dev
On Mon 12 Mar 2007, Tom Heath tom.heath@gmail.com wrote:
In a nutshell I'd like to use the OG sites as a source of geodata for items reviewed at Revyu.com.
Ooh, cool.
I took a quick look at revyu.com, not sure I can comment on it usefully, but I'm amused that Dan Brickley is among the "reviewed things".
Open Guides could be an ideal source (issues of global coverage aside), as long as I can come up with a reasonable heuristic for matching reviewed things in Revyu with their entry in a Guide.
If you can, that would possibly be useful for Guides that overlap - for example, the Oxford Guide and the Vegan Guide to Oxford, or the Tourist Engineer (is that still going?) and, well, every other Guide :)
Will let you know when/how it goes. Comments welcomed :)
Can you recommend an RDF browser for OS X?
Kake
Hi,
On 13/03/07, Kake L Pugh wrote:
On Mon 12 Mar 2007, Tom Heath wrote:
In a nutshell I'd like to use the OG sites as a source of geodata for items reviewed at Revyu.com.
Ooh, cool.
I took a quick look at revyu.com, not sure I can comment on it usefully, but I'm amused that Dan Brickley is among the "reviewed things".
:)
Open Guides could be an ideal source (issues of global coverage aside), as long as I can come up with a reasonable heuristic for matching reviewed things in Revyu with their entry in a Guide.
If you can, that would possibly be useful for Guides that overlap - for example, the Oxford Guide and the Vegan Guide to Oxford, or the Tourist Engineer (is that still going?) and, well, every other Guide :)
Good point. Revyu has the advantage of being able to narrow the scope of possible matches using some of the tags, but I guess the OGs could do that based on location data, which sounds even better.
Can you recommend an RDF browser for OS X?
This space is quite a mixed bag. My favourite is Disco Hyperdata Browser; it's browser based (in fact all the hard work is done on the server), so should be fine on OSX (do let the guys know if not!). And do bear in mind that it's a *triple displayer* and *linked data browser* (my words), so doesn't provide the kind of experience we're used to with the hypertext web ;)
Tom.
On 13/03/07, Kake L Pugh wrote:
Can you recommend an RDF browser for OS X?
On Tue 13 Mar 2007, Tom Heath tom.heath@gmail.com wrote:
This space is quite a mixed bag. My favourite is Disco Hyperdata Browser; it's browser based (in fact all the hard work is done on the server), so should be fine on OSX (do let the guys know if not!).
It seems to work fine, thank you!
OK, so I looked at an OpenGuides page in it: http://www4.wiwiss.fu-berlin.de/rdf_browser/?browse_uri=http%3A%2F%2Flondon....
It isn't very exciting! It doesn't tell me very much, and it doesn't link me anywhere[0]. It doesn't even link me anywhere else within the Guide. Shouldn't it be able to figure out things that are similar, things that are nearby? What do we need to do to OpenGuides RDF to make it more exciting and useful?
[0] Ticket #40 looks relevant - RDF people, what do you think? And how would you like to see it working? http://dev.openguides.org/ticket/40
Kake
On Thu 15 Mar 2007, Kake L Pugh kake@earth.li wrote:
OK, so I looked at an OpenGuides page in it: http://www4.wiwiss.fu-berlin.de/rdf_browser/?browse_uri=http%3A%2F%2Flondon....
It isn't very exciting!
Also, the Contributor looks wrong. How can we get that to point to actual-Bob, rather than just a random URI with "bob" in it?
Kake
Hi Kake,
Glad it works. You're not wrong, the output is pretty dull isn't it ;) The issue is this, which I'll hopefully be able to explain coherently...
URIs -------
The URI that you plugged in is the URI of a "wiki entry about Angel", SE16 4NB, not the URI of the thing itself. As a result the browser only outputs data about the page, not about Angel, SE16 4NB. To see that, you need to look at the URI http://london.randomness.org.uk/wiki.cgi?id=Angel%2C_SE16_4NB;format=rdf#obj in Disco: http://www4.wiwiss.fu-berlin.de/rdf_browser/?browse_uri=http%3A%2F%2Flondon.randomness.org.uk%2Fwiki.cgi%3Fid%3DAngel%252C_SE16_4NB%3Bformat%3Drdf%23obj or http://tinyurl.com/28pt4k. Hopefully we'd all agree this is a lot more interesting :)
One of the things that confuses this issue IMO is the Guides use of hash URIs, i.e. tagging #obj on to the end of the URI of a page about something, to make a URI of the thing itself. It's not a particularly pretty/ideal pattern to follow in an RDF world. Obviously it's grown up organically and we're dependent on many other modules, but ideally we'd use a URI pattern that went something like: http://wherever.openguides.org/thing-name-locale/ to identify things in the guide, with pages of information about the things being at http://wherever.openguides.org/thing-name-locale/about
Revyu follows this sort of pattern. Look up the URI http://revyu.com/things/far-from-the-madding-crowd-oxford in your browser, and you won't be returned the pub itself, but instead be redirected to a page with information about it. Replace the /html you'll likely get in the URL with /rdf for an RDF version. I'm guessing this isn't really very feasible for the OpenGuides right now, although liberal use of Apache Rewrite rules might get us a lot of the way. That aside, in the meantime we can concentrate on linking up the data in a more interesting way.
Linking within OG -------------------------
First off, one thing that would help would be to make a link between the <uriofpageaboutathing> and the <uriofthingitself>. This is lacking at the moment as far as I can tell, hence the lack of links from http://tinyurl.com/ynwxze to http://tinyurl.com/28pt4k. The foaf:primaryTopic property should be sufficient for this.
The next job is to fix some links in the RDF describing the thing. For example, http://london.randomness.org.uk/wiki.cgi?id=Angel%2C_SE16_4NB;format=rdf#obj is apparently foaf:based_near http://london.randomness.org.uk/wiki.cgi?id=Angel%2C_SE16_4NB;format=rdf#Rotherhithe Now, this may not be incorrect, but there is very little info about Rotherhithe at that URI. Instead we should be saying ... foaf:based_near http://london.randomness.org.uk/wiki.cgi?id=Locale_Rotherhithe;format=rdf That RDF file should then ideally contain lat/lon data about Rotherhithe, and links to all the things located in that locale. The same issue affects "bob"; rather than just linking to <somenodename;format=rdf#bob>, it would be great to identify Bob with a URI, http://wherever.openguides.org/contributors/bob/ perhaps; an easy win in the meantime would be to link (with rdfs:seeAlso I guess) to http://london.randomness.org.uk/wiki.cgi?action=rc;format=rss;username=bob;items=10, which at least starts to link up some of Bob's different entries, even if not in a very semantically rich way.
After that, we could get on to making links to the Categories that a thing is within, using the "find all things within x metres of this" to create some nice rdfs:seeAlso links (or even better, more foaf:based_near links), and things like that.
Linking outside OG ----------------------------
It would also be very cool to look at linking to other datasets, like you say. Revyu.com has a SPARQL endpoint against which you can do remote queries. So it would be relatively easy to do a query saying "give me all the reviews of things that have rdfs:seeAlso links to this particular page on the OpenGuides". We could then say that <thingonrevyu> owl:sameAs <thinginopenguide>, which would give us more links in browsers. It wouldn't catch all relevant things, as we can't assume that all reviewers in Revyu will link to relevant pages on the OpenGuides, but it would be a good start while we development more sophisticated location and/or string matching-based techniques.
Integration of the OpenGuides with GeoNames would also be a very cool and very easy win. For example, the URI http://sws.geonames.org/2639091/ identifies Rotherhithe, so with a bit of lat/lon-based validation it would be pretty easy to autogenerate these links for all Locales in all OpenGuides. Rotherhithe is described in RDF at http://sws.geonames.org/2639091/about.rdf. The GeoNames guys are very approachable, so there could be good opportunities for hookups with the OpenGuides in general.
OK, this emails mammoth, so I'll stop now.
HTH :) I can't promise to contribute code, but happy to advise on stuff like this,
Tom.
PS. If anyone else on this list is really into this stuff, then the Linking Open Data project http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData is doing some cool stuff in this space. OpenGuides is already listed under datasets.
On 15/03/07, Kake L Pugh kake@earth.li wrote:
On Thu 15 Mar 2007, Kake L Pugh kake@earth.li wrote:
OK, so I looked at an OpenGuides page in it: http://www4.wiwiss.fu-berlin.de/rdf_browser/?browse_uri=http%3A%2F%2Flondon....
It isn't very exciting!
Also, the Contributor looks wrong. How can we get that to point to actual-Bob, rather than just a random URI with "bob" in it?
Kake
-- OpenGuides-Dev mailing list - OpenGuides-Dev@lists.openguides.org http://lists.openguides.org/cgi-bin/mailman/listinfo/openguides-dev
On Thu 15 Mar 2007, Tom Heath tom.heath@gmail.com wrote:
The URI that you plugged in is the URI of a "wiki entry about Angel", SE16 4NB, not the URI of the thing itself.
Ah-ha, thanks, I'd not spotted that. Perhaps a quick fix would be to have the "RDF/XML" link in the navbar point to the URI of the thing itself, rather than the URI of the entry-about-the-thing? That seems to make more sense to me, in terms of doing the Expected Thing. After all, the interesting thing is the, well, thing, not the entry about it.
Lots of great ideas in your mail - thank you! I started going through and replying bit by bit, but pretty much everything was "yes, that sounds cool, we should be able to do that". So I'll just say it once, and it generally applies to the whole lot (some bits of it would, of course, take more work than others).
Do you think you'd be able to take the RDF output for that page, and edit in the stuff that you'd like to see there? Just so we have a reference for what we're aiming for. It's a lot easier to understand things when there's a concrete example.
Regarding "pretty" URIs, I'm not sure we should be trying to incorporate URI rewriting within OpenGuides itself - and consequently I don't want us to depend on it to the extent of writing our RDF on the assumption that it's there. Does a machine that's processing some RDF actually care that a URI isn't very attractive? And can't we use something like the rdf:Descriptionrdfs:label thingy in your Far
From The Madding Crowd RDF to protect people using browsers like the
Disco one from having to look at ugly URIs?
Incidentally, an idea for other Guide admins - Bob made this for me: http://london.randomness.org.uk/goodbeerguide which is memorable and easy to tell people (I just typed it in this mail, didn't go and look it up). Simple things like this can make it easier to persuade people to go and look at your Guide.
Kake
Hola,
On 15/03/07, Tom Heath tom.heath@gmail.com wrote:
One of the things that confuses this issue IMO is the Guides use of hash URIs, i.e. tagging #obj on to the end of the URI of a page about something, to make a URI of the thing itself. It's not a particularly pretty/ideal pattern to follow in an RDF world.
That was a very conscious decision on my part following the discussion on the "httpRange-14" issue within the W3C, which I'm sure you're familiar with. For those who aren't, the conclusion (which I believe postdated our implementation) can be found at http://lists.w3.org/Archives/Public/www-tag/2005Jun/0042.html . It can be summarised as "if your server responds with a 200 range code to a URI, it's an information resource; but anything within that resource with a fragment identifier is not". Our current behavior is in accordance with this, and I don't wish to change it. Why do you think it's not ideal?
Incidentally, "obj" itself was something I made up after failing to find a better alternative to the word "thing", which I have a strong dislike for. I'm happy for better suggestions.
Obviously it's grown up organically and we're dependent on many other modules,
Sorry? I don't follow... The RDF is completely independent of anything; it was hand-composed. Unless you're referring to schemata (yay Greek!) that we rely on as modules, rather than Perl modules?
ideally we'd use a URI pattern that went something like: http://wherever.openguides.org/thing-name-locale/ to identify things in the guide, with pages of information about the things being at http://wherever.openguides.org/thing-name-locale/about
Ideally for human readers? It's all much of a muchness to the robots... as long as the fragment identifiers are kept, I'm happy, though.
Replace the /html you'll likely get in the URL with /rdf for an RDF version. I'm guessing this isn't really very feasible for the OpenGuides right now, although liberal use of Apache Rewrite rules might get us a lot of the way.
A couple of years back I experimented with a pure-Perl method of doing better URLs (no rewrites required), which ended up with something like that. Nothing ever came of it, but I wouldn't mind resuscitating the idea.
First off, one thing that would help would be to make a link between the <uriofpageaboutathing> and the <uriofthingitself>. This is lacking at the moment as far as I can tell, hence the lack of links from http://tinyurl.com/ynwxze to http://tinyurl.com/28pt4k. The foaf:primaryTopic property should be sufficient for this.
Good call. I could have sworn we did this already, but obviously not. It's a trivial change.
The next job is to fix some links in the RDF describing the thing. For example, http://london.randomness.org.uk/wiki.cgi?id=Angel%2C_SE16_4NB;format=rdf#obj is apparently foaf:based_near http://london.randomness.org.uk/wiki.cgi?id=Angel%2C_SE16_4NB;format=rdf#Rotherhithe Now, this may not be incorrect, but there is very little info about Rotherhithe at that URI. Instead we should be saying ... foaf:based_near http://london.randomness.org.uk/wiki.cgi?id=Locale_Rotherhithe;format=rdf
(I think you mean http://london.randomness.org.uk/wiki.cgi?id=Locale_Rotherhithe;format=rdf#ob... ! Since it's not based near an RDF document.) But you could say that; alternatively, the wn:Neighborhood item "Rotherhithe" could be given an rdfs:isDefinedBy rdf:resource="http://london.randomness.org.uk/wiki.cgi?id=Locale_Rotherhithe;format=rdf#ob.... Your version is more compact, but doesn't specify that Rotherhithe is a wn:Neighborhood, which is an explicit definition that I quite like.
That RDF file should then ideally contain lat/lon data about Rotherhithe, and links to all the things located in that locale.
Sounds good.
The same issue affects "bob"; rather than just linking to <somenodename;format=rdf#bob>, it would be great to identify Bob with a URI, http://wherever.openguides.org/contributors/bob/ perhaps;
See above; it would have to be something more like http://wherever.openguides.org/contributors#bob , or, if we ever get formal logins, http://wherever.openguides.org/profile/bob#who ("who" being the equivalent of "obj" in this case, or again, whatever better name we can invent).
After that, we could get on to making links to the Categories that a thing is within, using the "find all things within x metres of this" to create some nice rdfs:seeAlso links (or even better, more foaf:based_near links), and things like that.
Yep.
[interesting ideas about Revyu skipped...]
Integration of the OpenGuides with GeoNames would also be a very cool and very easy win.... The GeoNames guys are very approachable, so there could be good opportunities for hookups with the OpenGuides in general.
Definitely worth us investigating.
OK, this emails mammoth, so I'll stop now.
Thanks for the input!
PS. If anyone else on this list is really into this stuff, then the Linking Open Data project http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData is doing some cool stuff in this space. OpenGuides is already listed under datasets.
I know you saw http://dev.openguides.org/wiki/RDF%20Workshop before, but there's a little bit of stuff I dumped on it towards the end relatively recently that may be of interest. The above link would be worth adding.
Best,
Earle.
Hey Earle,
On 16/03/07, Earle Martin wrote:
Hola,
On 15/03/07, Tom Heath wrote:
One of the things that confuses this issue IMO is the Guides use of hash URIs, i.e. tagging #obj on to the end of the URI of a page about something, to make a URI of the thing itself. It's not a particularly pretty/ideal pattern to follow in an RDF world.
That was a very conscious decision on my part following the discussion on the "httpRange-14" issue within the W3C, which I'm sure you're familiar with. For those who aren't, the conclusion (which I believe postdated our implementation) can be found at http://lists.w3.org/Archives/Public/www-tag/2005Jun/0042.html .
Sure. Great that the OGs are ahead of the curve on this. The httpRange-14 resolution is starting to get traction and does provide a decent means to move forward.
...It can be summarised as "if your server responds with a 200 range code to a URI, it's an information resource; but anything within that resource with a fragment identifier is not".
If I've understood the theory correctly, then yes, this is largely true and fine if you simply have an RDF document at the URI (in a document that defines an ontology, for example), but is incorrect if the information resource is an HTML document (where a fragment identifier identifies a part of the document, i.e. an information resource). Therefore we probably shouldn't make that assumption, but instead say "we don't know what a hash URI identifies". Richard Cyganiak covers this quite nicely I think:
<snip>If TimBL says that hash URIs always represent concepts, and not part of documents, then he contradicts RFC 3986 and introduces an ambiguity that is just as bad as the original "URI crisis" which httpRange-14 was designed to solve.</snip> http://dowhatimean.net/2006/11/content-negotiation-with-hash-uris-long
Our current behavior is in accordance with this, and I don't wish to change it. Why do you > think it's not ideal?
Sure, I can understand that. My preference (and it is a preference) for doing it differently comes down to the "hash URIs vs slash URIs" debate. I prefer slash URIs as I believe they make a clearer distinction between a thing and a document about a thing (and 303 redirects help avoid any ambiguity). They also send a stronger message about a URI of a thing being independent of any one particular document. For example, even though it makes no difference at the machine level, as a human being using http://london.randomness.org.uk/wiki.cgi?id=Angel%2C_SE16_4NB;format=rdf#obj to identify the pub in a different document would still niggle me a bit. It just seems the wrong way around; surely the pub is the primary object, and any particular description of it is secondary? Like I say, this is a preference, and I'm certainly not having a go at you about it, it's just my general opinion on hash URIs :)
Incidentally, "obj" itself was something I made up after failing to find a better alternative to the word "thing", which I have a strong dislike for. I'm happy for better suggestions.
I think it's fine, it follows the Ronseal approach. Would be interested in hearing you reasons for dislike of "thing", although you're welcome to save that for a face to face discussion over a beer sometime if you'd prefer.
Obviously it's grown up organically and we're dependent on many other modules,
Sorry? I don't follow... The RDF is completely independent of anything; it was hand-composed. Unless you're referring to schemata (yay Greek!) that we rely on as modules, rather than Perl modules?
OK, that's interesting, I hadn't realised that. What I was really getting at is that (as I understand it) the OG software relies on Perl modules for generic Wiki functionality (of course I may be totally wide of the mark here, having never really delved around under the hood). If that is the case then our ability to redfine the addressing scheme for OpenGuides and create "pretty URIs" may be limited, as the modules define the URI syntax. Please clarify things for me if I'm wrong about this.
ideally we'd use a URI pattern that went something like: http://wherever.openguides.org/thing-name-locale/ to identify things in the guide, with pages of information about the things being at http://wherever.openguides.org/thing-name-locale/about
Ideally for human readers? It's all much of a muchness to the robots... as long as the fragment identifiers are kept, I'm happy, though.
Yes, ideally for human readers. Sure, the robots don't care either way, but URIs will inevitably end up in human hands, so making them easily digestible is desirable IMO.
Just so I follow you, are you wedded to the fragment identifiers themselves, or simply the distinction between the "object/thing" and the "document about the object/thing"?
Replace the /html you'll likely get in the URL with /rdf for an RDF version. I'm guessing this isn't really very feasible for the OpenGuides right now, although liberal use of Apache Rewrite rules might get us a lot of the way.
A couple of years back I experimented with a pure-Perl method of doing better URLs (no rewrites required), which ended up with something like that. Nothing ever came of it, but I wouldn't mind resuscitating the idea.
Cool. Sounds good to me :)
First off, one thing that would help would be to make a link between the <uriofpageaboutathing> and the <uriofthingitself>. This is lacking at the moment as far as I can tell, hence the lack of links from http://tinyurl.com/ynwxze to http://tinyurl.com/28pt4k. The foaf:primaryTopic property should be sufficient for this.
Good call. I could have sworn we did this already, but obviously not. It's a trivial change.
Great. I only checked the london.randomness guide btw, so others may differ but I assumed it represented the state of the art as it runs 0.58 (the latest?).
The next job is to fix some links in the RDF describing the thing. For example, http://london.randomness.org.uk/wiki.cgi?id=Angel%2C_SE16_4NB;format=rdf#obj is apparently foaf:based_near http://london.randomness.org.uk/wiki.cgi?id=Angel%2C_SE16_4NB;format=rdf#Rotherhithe Now, this may not be incorrect, but there is very little info about Rotherhithe at that URI. Instead we should be saying ... foaf:based_near http://london.randomness.org.uk/wiki.cgi?id=Locale_Rotherhithe;format=rdf
(I think you mean http://london.randomness.org.uk/wiki.cgi?id=Locale_Rotherhithe;format=rdf#ob... ! Since it's not based near an RDF document.)
Indeed. Thanks, my mistake.
But you could say that; alternatively, the wn:Neighborhood item "Rotherhithe" could be given an rdfs:isDefinedBy rdf:resource="http://london.randomness.org.uk/wiki.cgi?id=Locale_Rotherhithe;format=rdf#ob.... Your version is more compact, but doesn't specify that Rotherhithe is a wn:Neighborhood, which is an explicit definition that I quite like.
The more semantics the better I reckon, so saying that it's a Neighbo(u)rhood would be great. Something like:
<uriForRotherhithe> foaf:isPrimaryTopicOf <documentAboutRotherhithe> <uriForRotherhithe> rdf:type wn:Neighborhood
might be a nice way to express these things (would need to double check this before commiting it to code); I'm not totally sure of the semantics of rdfs:isDefinedBy, so not sure if we can make such a strong claim as <uriForRotherhithe> rdfs:isDefinedBy <documentAboutRotherhithe> (hence foaf:isPrimaryTopicOf).
That RDF file should then ideally contain lat/lon data about Rotherhithe, and links to all the things located in that locale.
Sounds good.
Great :)
The same issue affects "bob"; rather than just linking to <somenodename;format=rdf#bob>, it would be great to identify Bob with a URI, http://wherever.openguides.org/contributors/bob/ perhaps;
See above; it would have to be something more like http://wherever.openguides.org/contributors#bob
Not necessarily. If http://wherever.openguides.org/contributors/bob/ returned a HTTP303 response and a "Location: http://wherever.openguides.org/contributors/bob/about" header, (where http://wherever.openguides.org/contributors/bob/about was a document describing Bob) then we'd be doing the right thing aswell. The # isn't essential.
Thanks for the input!
Any time :) Thanks to everyone on this list who has actually created and hosted the OG software so guys like us at the OGMK can come along and actually use it.
PS. If anyone else on this list is really into this stuff, then the Linking Open Data project http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData is doing some cool stuff in this space. OpenGuides is already listed under datasets.
I know you saw http://dev.openguides.org/wiki/RDF%20Workshop before, but there's a little bit of stuff I dumped on it towards the end relatively recently that may be of interest. The above link would be worth adding.
Cool. Will have a look. Agreed that the link would be worth adding. Have forgotten my Trac password, so will get around to requesting a new one at some point ;)
Cheers,
Tom.
Hi Kake,
On 15/03/07, Kake L Pugh kake@earth.li wrote:
On Thu 15 Mar 2007, Tom Heath tom.heath@gmail.com wrote:
The URI that you plugged in is the URI of a "wiki entry about Angel", SE16 4NB, not the URI of the thing itself.
Ah-ha, thanks, I'd not spotted that. Perhaps a quick fix would be to have the "RDF/XML" link in the navbar point to the URI of the thing itself, rather than the URI of the entry-about-the-thing? That seems to make more sense to me, in terms of doing the Expected Thing. After all, the interesting thing is the, well, thing, not the entry about it.
Great. Good idea.
Lots of great ideas in your mail - thank you! I started going through and replying bit by bit, but pretty much everything was "yes, that sounds cool, we should be able to do that". So I'll just say it once, and it generally applies to the whole lot (some bits of it would, of course, take more work than others).
:) any time, glad you liked them.
Do you think you'd be able to take the RDF output for that page, and edit in the stuff that you'd like to see there? Just so we have a reference for what we're aiming for. It's a lot easier to understand things when there's a concrete example.
Yeah, that sounds doable. Not sure what the timescale would be, as I have a stack of stuff on at the moment, but could probably do it on a "you let me know how soon this would be useful/how soon you need it" basis, and I could try to fit it in accordingly.
Regarding "pretty" URIs, I'm not sure we should be trying to incorporate URI rewriting within OpenGuides itself - and consequently I don't want us to depend on it to the extent of writing our RDF on the assumption that it's there.
Yeah, that's fair enough. If you can't depend on it then not worth the risk. Might there be a way to make it a config option??
Does a machine that's processing some RDF actually care that a URI isn't very attractive?
No, you're right, the machine doesn't care. But as in my reply to Earle, I'm certain that URIs will end up in the hands of humans, just as URLs have. <aside>I seem to remember reading somewhere that URLs were never meant to be an interface device (i.e. never meant to be manipulated by humans, enter into browsers etc). Unimaginable now isn't it?</aside>
And can't we use something like the rdf:Descriptionrdfs:label thingy in your Far From The Madding Crowd RDF to protect people using browsers like the Disco one from having to look at ugly URIs?
Yeah, absolutely, that's a good way to proceed. And in fact, despite what I said before, the Semantic Web, by moving us away from "documents" to things and statements, may actually be able to remove the URI/L from the interface (not that Disco or (m)any of the other SW browsers achieve this at present).
Incidentally, an idea for other Guide admins - Bob made this for me: http://london.randomness.org.uk/goodbeerguide which is memorable and easy to tell people (I just typed it in this mail, didn't go and look it up). Simple things like this can make it easier to persuade people to go and look at your Guide.
Cool. Will have a look at doing some of those for the OGMK. Did he just use rewrites to do it?
Cheers :)
Tom.
On Fri, 16 Mar 2007, Tom Heath wrote:
Incidentally, an idea for other Guide admins - Bob made this for me: http://london.randomness.org.uk/goodbeerguide which is memorable and easy to tell people (I just typed it in this mail, didn't go and look it up). Simple things like this can make it easier to persuade people to go and look at your Guide.
Cool. Will have a look at doing some of those for the OGMK. Did he just use rewrites to do it?
that one is just a straight Redirect instead of a rewrite.
so even simpler.
On Fri 16 Mar 2007, Tom Heath tom.heath@gmail.com wrote:
What I was really getting at is that (as I understand it) the OG software relies on Perl modules for generic Wiki functionality [...] If that is the case then our ability to redfine the addressing scheme for OpenGuides and create "pretty URIs" may be limited, as the modules define the URI syntax. Please clarify things for me if I'm wrong about this.
OpenGuides is built on Wiki::Toolkit (which we also have control over BTW - Dom's the official maintainer). Wiki::Toolkit does data storage and access - no CGI whatsoever. All the CGI is in OpenGuides.
Great. I only checked the london.randomness guide btw, so others may differ but I assumed it represented the state of the art as it runs 0.58 (the latest?).
It's got slightly hacked code and templates (a situation which I'm in the process of fixing), but it's basically 0.58. The RDF stuff seems to all be in OpenGuides::RDF rather than templates (apart from the site_index), and I'm fairly sure Bob hasn't touched that module; and I can't find anything about primaryTopic in the svn versions - so yeah, looks like it just wasn't done yet.
Kake
On 15/03/07, Kake L Pugh kake@earth.li wrote:
Do you think you'd be able to take the RDF output for that page, and edit in the stuff that you'd like to see there? Just so we have a reference for what we're aiming for. It's a lot easier to understand things when there's a concrete example.
On Fri 16 Mar 2007, Tom Heath tom.heath@gmail.com wrote:
Yeah, that sounds doable. Not sure what the timescale would be, as I have a stack of stuff on at the moment, but could probably do it on a "you let me know how soon this would be useful/how soon you need it" basis, and I could try to fit it in accordingly.
Basically, "whenever". I don't think we're short of other things to do in the meantime!
Kake
Cool, thanks for clarifying :)
I'll put the "ideal RDF output" on "when I have a spare minute and need something to do" list.
Cheers,
Tom.
On 16/03/07, Kake L Pugh kake@earth.li wrote:
On Fri 16 Mar 2007, Tom Heath tom.heath@gmail.com wrote:
What I was really getting at is that (as I understand it) the OG software relies on Perl modules for generic Wiki functionality [...] If that is the case then our ability to redfine the addressing scheme for OpenGuides and create "pretty URIs" may be limited, as the modules define the URI syntax. Please clarify things for me if I'm wrong about this.
OpenGuides is built on Wiki::Toolkit (which we also have control over BTW - Dom's the official maintainer). Wiki::Toolkit does data storage and access - no CGI whatsoever. All the CGI is in OpenGuides.
Great. I only checked the london.randomness guide btw, so others may differ but I assumed it represented the state of the art as it runs 0.58 (the latest?).
It's got slightly hacked code and templates (a situation which I'm in the process of fixing), but it's basically 0.58. The RDF stuff seems to all be in OpenGuides::RDF rather than templates (apart from the site_index), and I'm fairly sure Bob hasn't touched that module; and I can't find anything about primaryTopic in the svn versions - so yeah, looks like it just wasn't done yet.
Kake
-- OpenGuides-Dev mailing list - OpenGuides-Dev@lists.openguides.org http://lists.openguides.org/cgi-bin/mailman/listinfo/openguides-dev
openguides-dev@lists.openguides.org
-
Bob Walker -
Chris Prather -
Christopher Schmidt -
Daniel Alexander Smith -
Dominic Hargreaves -
Earle Martin -
graham -
IvorW -
jesse -
Kake L Pugh -
Nick Burch -
Tom Heath