|
I'm part of a team working on enhancing the specification used by podcasters across the world to produce open RSS feeds that describe their podcasts. These are used by hundreds of thousands of different publishers as the main syndication format to get their podcasts into podcast apps like Apple Podcasts and hundreds of others. The open nature of podcasting means there's nobody really "in charge", and I have no lawyers to ask questions to. I'm also an active OSM Foundation member, and contribute regularly to the local map of my area. My proposal for a "podcast:location" specification is to incorporate the type and ID of an OSM object. You'll see the current proposal here: https://github.com/Podcastindex-org/podcast-namespace Recognising that an OSM ID is not permanent, but cities and countries are "permanent enough" for this use, this is to allow podcast apps and search engines to be able to answer the question "where are some good true crime podcasts near me?" or "what shows are about the place I live in"? An example of the spec being used is: ... which in this case links to the Relation type, ID 1567699, which is actually marked "Palace of Westminster" in OSM. The "osmid" in this is optional. Use of any data discovered from OSM in any form would require use of the full OSM database, of course. But my question is: Will the presence of the ID and type within the open RSS feed - without any other OSM data - require attribution inside the feed itself? I would hope that this would be appropriate use of OpenStreetMap identifiers, and enable significant publicity for the OSM project as a whole. There are 1.5m podcasts currently available, and this world is growing rapidly. Guidance on attribution would be very much welcomed. |
|
Having now discovered and read this page I think I'm now comfortable that attribution is not required. Thank you to @Tzorn for the suggestion of Wikidata. Since they suggest that "Relation" type OSM IDs are stable enough for this use, that would be my recommendation too - use of OSM rather than Wikidata seems the most sensible option for our use, since OSM data is considerably more structured and useful. So I've amended the specification to specify that only "Relation" type IDs may be used. |
Not an answer to your question but have you considered referencing a wikidata item? Many OSM objects in turn reference the corresponding wikidata item and you could make the match this way. This could be a way around relying on only fairly stable OSM IDs but not sure current coverage is good enough.