On Tuesday 04 November 2008, 07:01:09, Matt Amos did write: > On Mon, Nov 3, 2008 at 6:47 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote: > > If the only thing that connects two objects is that they have a common > > property, I'd say a relation is not the way to model that. >
I have been holding back on saying this for a while because (a) I know relations have come a long way, and (b) without doing more constructive planning or development, I really have no right. Still, this might inform future discussion. I had a very different different idea of what relations were before I looked at them properly. I was disappointed to see that they just appear to be named groupings. … > i think you're right. mathematically speaking, set membership by > shared properties and explicit references are identical, but that > doesn't mean that we should treat them as interchangeable :-) > +1 … Disappointed because it doesn't seem to add anything that I can see. You can already do this, as Frederick says, by assigning common properties. That said, I guess there's a performance advantage, but that is of no interest to me in the role of mapper. Optimise away from the interface (if that's what's going on). So it's more of a grouper AFAICS, far from intuitive (in a moment, I'll illustrate by explaining my original expectations) and, as Matt is saying, a little arbitrary in application. Perhaps even a renaming to "groups" would help. > it also seems to me that (generally) relationships should indicate > locality, as this is more meaningful in the context of bounding box / > map calls. i.e: when i resolve all members of an ldp / route / turn > restriction, those members (if they are complete) should be connected. > likewise, if i resolve members of an addr:associatedStreet, i would > expect the houses to be quite close to the street. > This is closer to what I expected. Something like – if you'll forgive me donning my astronaut helmet for an excursion into space – what Dublin Core do with the is* and has* properties (e.g. isPartOf and hasPart) and more generally what we have with RDF predicates, i.e. A [relationship] B. Here's a couple of uses cases I originally thought I would use relations for, before I found out they were not much more than groupings (again, I'm often wrong, so please correct this if so): 1. A bus stop has a relationship to a road. It's not on it, and it can be tricky to infer it (snap it) with routing software. So I thought I might be saying "Bus-stop isAdjecentTo Road" or maybe "Bus-stop serves Road". This is kind of what the left-right proposal was trying to _achieve_. 2. There are several split roads in my area. I thought I'd be able to tag "WayA isSameAs WayB". I guess that's more for street name searches and indexes than for routing. You wouldn't necessarily want to find a street listed three times in an index. Now that's off my chest. Possibly that's all this contribution is good for. Even as a distraction, I'd be interested to hear any views about it. Thanks if you read it. :~) Cheers - Hugh _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
