hi re, sorry dropped thread, this is a longish one, more openguides stuff below...
share it among 3 people. i think we're going to get a lot of that. does that make any difference?
nnng; perhaps, in a worst case; if i start reasoning about things based on those properties which i acquire from you; if i had other information about more than one of those people, if more than one of them became associated with that address, i might accidentally collapse them into a multi-limbed, polypresent uber-person. This, however, is largely my problem.
So if i start using a squishing algorithm to create identities from FOAF data while you're publishing unique identifiers for non-unique things; which are identifiers that i'm likely to hear repeated from other sources... well, i can be more cautious about what i accept from the world and start making new conclusions with. And you can be cautious about what you emit... but do you want people to have to set a 'this is a group account' flag and not emit email addresses? Perhaps it's just okay to not worry about it.
right, i didn't realise the RDF/xcal representation was going to be somewhere else as well. if the changes.rss could offer rdfs:seeAlso links to fuller RDF representations that would be ideal.
okay. i'm not too clear on syntax around this kind of thing. given that we want to retain some kind of pubDate, and have seeAlsos, etc, what would an <item> look like now?
well, i don't know what predicate/property to recommend using to indicate pubDate as a concept in RSS1 that doesn't affect the semantics of what you're talking about. perhaps just having a pubDate / ical:datetime / whatever on the item, and differentiating between the item (the uri of the page about the object (the event)) and the object actually under discussion.
Have a look at: http://london.openguides.org/api/rdf/category/Bookshops
That features an RSS feed with seeAlso links which are to the RDF version of each URI. If you look at http://london.openguides.org/index.cgi?id=Freedom_Bookshop;format=rdf
You see it differentiates between properties of that URI, the page containing information about the thing, and the relative URI #obj which is the URI which refers to the actual thing in itself.
Does this make sense? It is a nuanced issue the background of which you can dig at with a search for "HTTP-Range-14". It may sound a little obtuse but i found it later helpful when modelling metadata properties of things (people, spaces), rather than descriptions of or references to things (wiki pages, web service URIs)
Re. the broader hookup between OGL, EVNT and wirelesslondon:
- We'd get a feed from EVNT anyway, of stuff we'd been able to reason was nearby. for WirelessLondon, we'd probably want to consume everything you thought was in London, up front. We'd want to share this with the Open Guide to London; and OGL will offer a kind of fuzzy node-coder service, so you can send an address string, see if OGL has anything that matches your place/venue, and attach your evnt to it; this should be one-click for the user; then easy to POST new pages, which perhaps can be wiki-gnomed and made into redirects later, if auto-generated page node titles aren't to the Guide admins' tastes.
- Someone logs into Wireless London via the portal service. They could do this via the web as well; we don't *force* them to authenticate to the portal, they can pass straight through if they like. Each node knows where it is, and shows a listing of local resources from the Open Guide; ideally, EVNTs that we've managed to geocode within 1000m. Once the user logs in, we have their personal information that they gave us when they registered; it is just part of a big old triple store into which we are also aggregating RSS, geo, FOAF data. If we have mbox_sha1sum annotations from you, we say, "here's an event you've annotated, therefore this is probably your evnt account, log in here".
If we can really get people using this service - i've toyed with the idea of *obliging* the Season of Media Arts for London organisers to use the portal service, they don't get access to their tools via the web - this means they have to go socialise in a cafe with open wireless, or set up a Wireless London portal node at home ;) - well, we get a lot of for-free association.
We know where the user is in space, and in time, and we know *who* they are, what information resources they are connected to. And we are starting to know a lot more about the things around them, in space and time and more abstract network sociality; from EVNT and from the Guide particularly.
Because it is being accessed with a knowledge of these properties, the system starts to refract connections in the information near them. I'm connecting to the network; I'm in a cafe in South Kensington; my calendar says i'm supposed to be at a meeting at the Data Centre in an hour's time. Saul will be there, and i have a postponed mail waiting to go to him two days now, and...
I should stop there, but perhaps others have more of that picture. Almost without architecture, just through the edges, we can almost do amazing things.
-jo