On Sat 03 Mar 2007, IvorW <ivorw-openguides(a)xemaps.com> wrote: 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. 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. Thanks! Kake

On Sun, Mar 04, 2007 at 03:29:01PM +0000, Kake L Pugh wrote: On Sun 04 Mar 2007, Christopher Schmidt <crschmidt(a)crschmidt.net> wrote: 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: 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

On Sun 04 Mar 2007, Nick Burch <openguides(a)gagravarr.org> wrote: 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, 4 Mar 2007, Kake L Pugh 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). Nick

On Sun, 4 Mar 2007, Kake L Pugh 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? 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, Mar 05, 2007 at 04:32:23PM +0000, Kake L Pugh wrote: +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. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

On Fri 09 Mar 2007, Dominic Hargreaves <dom(a)earth.li> wrote: (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 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

On Fri 09 Mar 2007, Tom Heath <tom.heath(a)gmail.com> wrote: Ooh, cool. What are you going to be doing with it? Kake

On Mon 12 Mar 2007, Tom Heath <tom.heath(a)gmail.com> wrote: 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". 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 :) Can you recommend an RDF browser for OS X? Kake

On 13/03/07, Kake L Pugh wrote: On Tue 13 Mar 2007, Tom Heath <tom.heath(a)gmail.com> wrote: 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… aka http://tinyurl.com/ynwxze 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

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 &lt;kake(a)earth.li&gt; wrote:

Hi Kake, On 15/03/07, Kake L Pugh &lt;kake(a)earth.li&gt; wrote: Great. Good idea. :) any time, glad you liked them. 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. 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?? 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> 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). Cool. Will have a look at doing some of those for the OGMK. Did he just use rewrites to do it? Cheers :) Tom.

On 15/03/07, Kake L Pugh &lt;kake(a)earth.li&gt; wrote: On Fri 16 Mar 2007, Tom Heath &lt;tom.heath(a)gmail.com&gt; wrote: Basically, "whenever". I don't think we're short of other things to do in the meantime! Kake

Hey Earle, On 16/03/07, Earle Martin wrote: 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. 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> 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 :) 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. 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. 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"? Cool. Sounds good to me :) 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?). Indeed. Thanks, my mistake. 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). Great :) 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. 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. 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.

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 &lt;kake(a)earth.li&gt; wrote:

On Sun, 4 Mar 2007, Kake L Pugh wrote: 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. -- Bob Walker http://www.randomness.org.uk/ Stress Kittens: Squeeze them till they cry! The latest tech in homicidal tendency relief.

On Sun, 4 Mar 2007, jesse wrote: indeed. that was the plan. althogh admiitedly its not outside the realms of possibility that spammers can set up spam LJs. -- Bob Walker http://www.randomness.org.uk/ Stress Kittens: Squeeze them till they cry! The latest tech in homicidal tendency relief.

On Mon, Mar 05, 2007 at 01:04:39AM +0000, Daniel Alexander Smith wrote: 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, -- Christopher Schmidt Web Developer