(re)modelling space

context: we have a simple RDF model of connections between spaces, where one node has a property that 'connects' to another

(original RDF)

problem: this model isn't interesting enough; we can't state anything about the connection

and there are lots of things we want to state, like its lat/long/alt, whether it's accessible to cars or bicycles or people, or limited in access to certain times of day, or when it came into existence or ceased existing; and of course who created it and may have amended it in the model. we cn state these things about spaces, or points, or anything we choose to identify; but we can't identify a connection in order to talk about it

solution space: several ways to enrich the connection.

one approach would be to use reification. here, we'd take a simple statement (X connects to Y) and build a meta-statement about it, to which we can refer.

[#anonConnection rdf:subject http://space.frot.org/a_space/London/Oxford_Street]
[#anonConnection rdf:predicate http://frot.org/space/0.1/connects]
[#anonConnection rdf:object http://space.frot.org/a_space/London/Tottenham_Court_Road]

There are big drawbacks with this approach. It's overcomplex, involving the creation of three extra metastatements every time you state something. It's harder to read, makes even less 'intuitive' sense than most serialised RDF. And reification is not implemented in most scutters or aggregators; it we want to annotate things with geo points, or times, it makes it much harder to infer whatever it was we were originally talking about.

another approach is to use one level of indirection. instead of connecting directly, we connect to an intermediate node which encapsulates the connection. it could be thought of as a kind of event, or state-of-affairs. the intermediate node we can annotate with creator, time and space properties.

[http://space.frot.org/a_space/London/Oxford_Street space:connects #anonConnection]
[#anonConnection space:connecting http://space.frot.org/a_space/London/Tottenham_Court_Road]
[#anonConnection geo:lat 51.344535]
[#anonConnection ical:dtstart 17341204Z102345]
... etc etc

problems with this approach; it makes the model harder to reason about, and harder to query: disrupts the simplicity in the way the reified version somehow doesn't.

we could abstract out the connection into a separate node.

here, it looks harder to state things (logically) like 'you can only turn left from Oxford Street onto Tottenham Court Road'; but perhaps that's something one could infer from the one-way-ness of a stretch of Tottenham Court Road. but this feels appealing as a solution.