Updating the "Sources" field to edit source:*= tags

[Minh_Nguyen]

@Pedro_Leao

It only shows predefined tags that are supported, which are currently source:name, source:url and source:date, since they are the most used ones on taginfo. I thought about allowing users to insert whaterver tag in the format source:*= they wanted, but that would make the field have the same functionality as the tag editor, in which case it would be simpler to just use the tag editor itself.

I agree, we don’t need to reinvent the raw tag editor here. However, do you think the user might expect these subfields to behave like the raw tag editor, given the similar-looking button and two-column layout? If we don’t expect this field to contain an arbitrary number of subfields, maybe we could simplify it to show all the supported subfields at the same time? That would be consistent with the address and date fields, which remain compact by labeling each subfield using placeholder text.

source=* is currently much more popular than all of the subkeys combined. However, the user would see that they can add a name and a URL on other rows via the dropdown, so they may wonder what the topmost, full-width row is supposed to contain. Actually, I’m not sure I know the answer to that. If we formalize the use of source:name=* and source:url=*, then source=* seems like it would have no purpose in most cases. On the other hand, if source=* is supposed to contain a URL, as suggested when citing a tile server, then we shouldn’t offer a redundant subfield for source:url=*. But in that case, should the user omit source=* when citing an offline source or one that’s only accessible online via a subscription database?

@jeffmeyer

Oversourcing can certainly be a problem (one I’d love to have). But, under sourcing is a problem, as well. I believe the rule of thumb in academic research is to have at least 3 sources for any claim.

Sometimes it is useful to cite multiple sources for the same fact, but I think a three-citation minimum for every fact may be an oversimplification. Maybe it depends on the field of study. In the archaeological and historical sources I’ve consulted, I tend to see only one citation per fact, sometimes more if the statement is a synthesis or an extraordinary claim. For example, the Newberry Library’s county boundary dataset typically contains only one citation for the whole feature, occasionally two.

If we ask for too much detail at once, we may risk discouraging mappers from citing their sources. When preparing an import or other bulk edit, you can take your time to perfect the one citation you plan to repeat across the entire changeset, but when you’re mapping a wider variety of features, citing a source needs to be something you can do quickly and then move on. As far as I can tell, so far, the vast majority of occurrences of source:# and source:name come from imports or other bulk imports uploaded through JOSM, not more bespoke edits in iD.

I expect that the improvements @Pedro_Leao is making will promote these subkeys to some extent, but I’m not very confident that we’ll get to 100% coverage without a more organized effort. On Wikipedia, if you add a bare URL as a citation, eventually a bot will come along and automatically fill in a title based on the page title, maybe some other details. Then another bot will make sure the Wayback Machine has archived the URL and link to the archive as a backup. If we can run a bot like this, then mappers don’t need to worry as much about getting all the details right on the first try. Even so, we’ll want iD to support these subkeys so that the filled-in details can be visible to the user.