Refactor predicates for way nodes and relation members

[patrickbr]

Currently, the predicates for way nodes and member relations look as follows:

osmrel:51477 osmrel:member ?member_ref .
member_ref osm2rdfmember:role ?member_role .
member_ref osm2rdfmember:pos ?member_pos .
member_ref osm2rdfmember:id ?member_id .

osmway:100 osmway:node ?node_ref .
?node_ref osmway:node ?node_id .
?node_ref osm2rdfmember:pos ?node_pos .

This is inconsistent and confusing (especially the usage of osm2rdfmember:pos for way node positions, and the double usage of osmway:node to point to the ?node_ref, as well as to the ?node_id.

After some discussion with @hannahbast, this PR changes the predicates to look as follows:

osmrel:51477 osmrel:member_ref ?member_ref .
member_ref osmrel:member_role ?member_role .
member_ref osmrel:member_pos ?member_pos .
member_ref osmrel:member_id ?member_id .

osmway:100 osmway:node_ref ?node_ref .
?node_ref osmway:node_id ?node_id .
?node_ref osmway:node_pos ?node_pos .

I also renamed osmrel:completeGeometry to osmrel:hasCompleteGeometry.

[patrickbr]

Note: tests are currently failing for the reasons explained in #110

[1ec5]

Thanks for this refactor. It would be an improvement, though I think there’s an opportunity to streamline the design a little bit. Hope this helps.

[1ec5]

“Ref” is somewhat confusing because ref=* is a very common key on both relations and ways. If you renamed member only for consistency with osmway:node_ref, I’d suggest calling the latter osmway:member instead, to avoid the need for this _ref suffix. This is how OverpassQL refers to the concept.

If you need the predicate of a way to have a different name than the predicate of a relation, then I’d suggest osmway:vertex. The analogy is that a vertex is to a way as a member is to a relation. The “vertex” terminology is used by editors, so mappers would be familiar with it. It also suggests a possible future enhancement for indicating the angle of the way at the vertex.

(Mappers sometimes distinguish between a node that’s part of a way and a POI that stands alone, but this is very informal and risks confusion with semantic POIs that can be mapped as ways or even relations.)

[patrickbr]

Thank you for the feedback! So just to make sure I understand you correctly, you would prefer the following design:

osmrel:51477 osmrel:member ?member .
?member osmrel:member_role ?member_role .
?member osmrel:member_pos ?member_pos .
?member osmrel:member_id ?memer_id .

osmway:100 osmway:member ?member .
?member osmway:member_id ?member_id .
?member osmway:member_pos ?member_pos .

Or, alternatively

osmrel:51477 osmrel:member ?member .
?member osmrel:member_role ?member_role .
?member osmrel:member_pos ?member_pos .
?member osmrel:member_id ?memer_id .

osmway:100 osmway:vertex ?vertex .
?vertex osmway:vertex_id ?vertex_id .
?vertex osmway:vertex_pos ?vertex_pos .

[1ec5]

Yes, correct. I don’t have a strong preference between the two designs.

[patrickbr]

I would then prefer osmway:member. It would be closer to our original design and therefore introduce only minor changes.

@hannahbast, is this ok for you? I know that I argued against using osmway:member 2 days ago because a way node is not strictly a "member", but OverpassQL indeed seems to use the "member" concept also for nodes, so this is already established in the community. And it does feel natural here.

[patrickbr]

This is now implemented in 063183c