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

[jeffmeyer]

@Minh_Nguyen

Ah, cracking open OSM’s old religious wars, I see.

Perish the thought! If I’d known that was what I was cracking open, I’d have chosen discretion as the better part of valor. I was, for the record, an OSM religious war draft dodger!

@Minh_Nguyen

In OSM, the source:* format seems to have won out pretty decisively. I don’t know all the arguments on either side, but OHM has some considerations that probably never came up in OSM. If we want to depart from OSM, we’ll have to be very deliberate about it with improved editor support. We’ll also have to keep in mind these differences as we build tools to help mappers transfer content from OSM to OHM when it no longer suits OSM.

In this case, source:* format means like source:start_date=* is the source of the start_date=* tag, correct?

@Minh_Nguyen

The *:source format makes a lot of sense if we’re going to tag each citation in structured format, isolating each piece of metadata into a separate tag. OSM never needed to do this, because the principle of on-the-ground verifiability normally limited sources to primary observation (untagged), tracing from imagery layers (automatically tagged on changesets), and imported online databases (which are detailed on import pages on the wiki). Rarely would someone need to cite, say, a newspaper article by its author, title, publication, date, and page.

This pulls a thread I failed to include in my prior post: the general source:a:b:c=* tagging is more about the geometry drawn on the map. The *:source tags are about the characteristics of what the geometry represents. I think. Is that correct?

@Minh_Nguyen

So far, no editor supports the *:# indexed syntax. … I’m curious if this was just because the proponents of these schemes never pushed them as far as they needed to, or if there was a flaw that prevented editors and data consumers from supporting the indices.

This would be very good to know. I think the editors do support the syntax, but only as free-form text entries, not as any sort of supported validation, autocomplete, etc.

One catch is that the OHM inspector supports enumerated tags for at least a couple of UI-exposed items: images and additional information links, which were intended to help users enrich the left-nav description of what they’ve mapped. See here.

and here:

@Minh_Nguyen

To the extent that mappers have been tagging both the title and URL to a source, there seems to be two approaches to tagging them side-by-side:

• source contains the title, and source:url contains the URL.
• source contains the URL, and source:name contains the title.

The former assumes that every source has a title, while the latter assumes that every source is reachable online at a permalink. Neither assumption holds in every situation, so it seems like we’d need to allow source to go untagged sometimes, or expect software to gracefully handle either a URL or a non-URL in source.

Totally agree.

@Minh_Nguyen

@jeffmeyer

The sourcing should travel with the object. So, each object needs its own source information. This may seem onerous, but a commitment to this principle helps ensure that all downloaded data, regardless of filtering, is either properly attributed or could be attributed.

How does this principle square with OHM’s convention of elaborating on the sources on community project pages on the wiki? To the extent that mappers follow this convention, the project pages stand a better chance of staying up-to-date with URL changes and the like.

I’d suggest that few of our conventions are rock-solid yet, or certainly rock-solid enough to use as definitive guidance. I do think community project pages are important, especially for describing process, goals, inspirations, etc. But, at the end of the day, I’m expecting people to download the entirety of the OHM database for information and not the wiki. Likewise, I believe there will always be more OHM projects than project pages, even as valuable as they are.

@Minh_Nguyen

But we’d need a consistent convention for referring to sources that are detailed elsewhere. I suppose some licenses also impose restrictions on how directly or indirectly we may incorporate a citation.

Indeed, and the closer we can put the citations to the actual data being cited, the better. We could even be a standard-bearer in this area. Or, at least try to be.

@Minh_Nguyen

I’m reminded of the two common practices for citing sources on Wikidata. Some references (citations) are detailed in situ while others are represented by a simple stated in (P248) statement, sometimes with an extra pinpoint ID. In the long arc of time, every distinct work used as a source would have its own item there, but detailing the source’s metadata in situ is a reasonable first step. This would result in indirect citations if you only look at the raw XML, but as long as the user-facing website always resolves the citations, making them usable, then any charges of plagiarism can be avoided.

We could even outsource some of this metadata to Wikidata, relying on that project to supply the more tangential details about a source. As part of its WikiCite initiative, Wikipedia has been developing an approach in which it would store only the QID of a Wikidata item, plus pinpoint information like page numbers and excerpts. The main challenge is that we’d need to establish two-way communication with the Wikidata community so that items about sources don’t get deleted by accident. The Name Suggestion Index project has some experience managing this risk with the items it needs; overall, the partnership with Wikidata has been highly beneficial.

Totally agree that this should be our target - to have some sort of citation lookup system and I hope we can draft off of / act as a poster child for Wikicite. Also agree with your concerns about 2-way comms. That said, until then, I think we’re a little stuck… unless someone here has a clever idea?