Please don't forget to use the source=* tag (Case study!)

General
,
13

Ok - this has been a mind-expanding thread, and conversation appears to have tapered off, so I’d like to attempt to summarize and consolidate the discussion to see if we can turn it into an action plan for getting to some more finished documentation. Hopefully, I haven’t mischaracterized the discussion so far.

Geometry vs. Metadata sourcing:
Differentiating between these two categories of what we map in OHM was very helpful to me, especially in regard to how we tag them.

It seems all of the source tags fall into these 2 categories, and the original post implied:

  • Geometry tagging: use source: without a prefix, as if it’s actually geom:source:xxxx=* as described by @Kovoschiz here. These will most often refer to items shown on a source map.
  • Metadata tagging: append :source to the metadata prefix key. These source tags often refer to information not obviously derived from a source map.

This leads to a few questions also identified in the thread - e.g. Should we:

  • Explicitly use a geometry prefix of some sort? @kovoschiz pointed this out. Should we have keys like geom:source, node:source, way:source, etc.? If so, which one? Or, should we just assume that without a prefix, “source” refers to the implied “geom”? Benefits of an explicit geometry key would include clarity and consistency across keys and less confusion about what the source reflected. Costs would be longer keys and some retooling (probably true of whatever we decide (for now… see below)).

Other source-related questions

Should we:

  • Require a minimum base geometry (implicit or explicit) source tag of some sort? @Minh_Nguyen pointed out that having a subkey like source:name might imply that the source key has a value. Or, could/should we support as “pick-one-of-three” or “one-of-two” from source=name or url, source:url=*, and source:name=*.

  • If we have a minimum required source tag, should that be a short text citation? @Ashton747 proposed a this system here and @AndrewS_OHM added to it with an added wrinkle of maybe including multiple sources separated by semicolons. Andrew also pointed out that most mappers for a particular area would know the maps that are available for a particular point in time. [my experience is: “I wish!”]

  • Store bibliographies on a community project wiki page and link to that using source:url? This was suggested by Andrew & Minh raised a similar point. Or support both that system and direct URLs to sources? e.g. an ohm_project=url key? Benefits are that community project pages provide a much better description of how the data was sourced and aggregated than a simple link. Cost is that not all mapping is big enough to justify creating a project page. And, community pages aren’t machine readable for gathering sources.

  • Encourage a particular citation formatting? @Kovoschiz brought this up and proposed an abbreviated format. If so, which one? Here’s the Chicago format for map citations, as hosted by the Library of Congress. Yowza.

  • Adopt an approach for inference-based sourcing, particularly for start_date and end_date tags with unclear sources, but some degree of confidence? @Minh_Nguyen talked about this and I’m guilty of very incorrectly citing start_date=arbitrary and end_date=arbitrary when those tags, while arbitrary, were also most likely bound by some other assumptions that my tagging didn’t reflect.

Static vs. Dynamic Sourcing
All of our current modes of tagging are fairly static, rigid (e.g. no rdb triplets) and unliked (outside of an explicit URL…). Much more interesting alternatives like Wikicite, as mentioned by @Minh_Nguyen, are on the foreseeable horizon.

If you haven’t looked at Minh’s examples above (2nd para from bottom of post), which often cite a source and have a means of adding a “pinpoint” lookup within that source, please do so. It’s not too far of a leap to think of a source as a map and a pinpoint as a literal… point… on the source map. Very exciting and the way map citations are moving, especially with computer vision and machine learning.

My take is that backend and frontend tooling and user training still require too much work to go to a solution like this now, but maybe that perspective is too entrenched in the past and we should move forward now? Or, at least, maybe support both methods, so the future is available now for those who want to press forward?

Even if we don’t move forward now, we should definitely think of how our current sourcing might be migrated to a richer structure in the future and not back ourselves into a hole.

Moving Forward
I’ve set up some polls to get a sense of general consensus on these topics across our forum dwellers and turn the consensus into some “as of now” documentation to use as a reference while we continue to discuss next steps. Not sure if polls are the best method for resolving anything, but we can give them a shot, no?