Proposal - podcast:location (again)

[jamescridland]

Lots of discussion in other threads, and I thought it might be helpful to produce a straw man based on those discussions.

This post is often edited to reflect the discussion below. You can view the history of this post to see the edits.

podcast:location

(11 Dec, v4.1 - a short note on privacy in the UX suggestion section)

Channel (optional | multiple) Item (optional | multiple)

This is intended to describe the location of editorial focus for a podcast's content - i.e. "what place is this podcast about?"

The use-cases for podcast:location are multiple, in order of complexity:

1. To allow a free-text "location" field to be visible in a podcast app, perhaps during playback
2. To allow a simple point on a map to be visible in a podcast app
3. To allow a search for "podcasts/episodes about places near me" - for, for example, a travel or news podcast
4. To describe a specific place in a programmatic fashion to allow complex geo-aware searches

If this proposal is accepted, and a podcaster uses the recommended tags, it may allow very complex searches such as:

• Show me podcasts or episodes about places near me
• Show me podcasts about train stations in Germany
• Show me podcasts about mines in West Australia
• Visa mig podcaster om platser i Kalifornien på svenska - "Show me podcasts about places in Californian, returning Swedish-language podcasts only" (using the <language> tag)

Unlike other elements in this namespace, a "place" is not permanent. Places are built, and abandoned, all the time. Buildings are demolished, businesses close.

On the other hand, a point on the earth is permanent, but does not describe anything other than a point. This is not always great when wanting to describe a city, rather than an area in a city, or a restaurant within a city. This comment describes this in more detail.

'Locations' are not always real places, especially in fiction podcasts.

This therefore means that the podcast:location tag is complex and has a number of attributes.

Specification

<podcast:location
  name="[humanly readable place name]"
  geo="[geoURI]"
  osmid="[OSM type][OSM id]"
>

mandatory: name="[Humanly readable name]" - this is meant for podcast apps to display the name of the location that the podcast is about. Examples might be "Houses of Parliament", "Gitmo Nation" or "Ernest Murrow Theater, Chicago"). This is not intended to be programmatically parsed and is for display only. For a programmatic designation of the location, use OSM IDs, below.

This field is a maximum of 64 characters. It may describe a real or fictional place. It should be in the same language as the podcast, as indicated in the <language> RSS tag: so a podcast in en should read Eiffel Tower, Paris and not La Tour d'Eiffel.

recommended: geo="[geoURI]" - a geo URI, conformant to RFC 5870. Examples:

• geo:37.786971,-122.399677 (a simple latlon description)
• geo:37.786971,-122.399677,250 (a latlon including a height of 250 meters above ground level)
• geo:37.786971,-122.399677;u=350 (a latlon with an accuracy ('uncertainty') of 350 meters). For information that may interest space travellers: the RFC does include an optional coordinate reference system for other planets, though these are not recommended to be used yet by the RFC.

geo is recommended to be used alongside an OSMID. Since OSM IDs are not guaranteed to be permanent (perhaps it's the ID of a building which is later demolished), the geoURI serves as a permanent point. Exceptions are podcasts from, or about, fictional places. Data within these tags must relate to a real place.

recommended: osmid="[OSM type][OSM id]" - from an OpenStreetMap query. If a value is given for osmid it must contain both 'type' and 'id'. osm type: A one-character description of the type of OSM point. Valid is "N" (node); "W" (way); "R" (relation). osm id: The ID of the OpenStreetMap feature that is described.

This may describe part of a building, a building or business, a suburb, city, state, or country - anything within the OSM database, using the OpenStreetMap API or a local copy of the data. This is the field that is the best programmatic representation of the place being described. The data within OpenStreetMap is rich and can be used for detailed searches.

Examples:

• The United States of America: [R148838](https://nominatim.openstreetmap.org/ui/details.html?osmtype=R&osmid=148838)
• The Eiffel Tower in Paris: [W5013364](https://nominatim.openstreetmap.org/ui/details.html?osmtype=W&osmid=5013364)

osmid is recommended to be used alongside a geo tag. Since OSM IDs are not guaranteed to be permanent (perhaps it's the ID of a building which is later demolished), the geoURI serves as a permanent point. Exceptions are podcasts from, or about, fictional places. Data within these tags must relate to a real place.

If a developer uses the osmid tag, the canonical latlon is the one returned by OSM. It is intended that the geo tag is used for simple display within a podcast app without any API usage: but for more advanced uses, like a geographic search, developers will ingest the full details from OpenStreetMap. The geoURI also offers a useful fallback should the osmid be removed.

_Caution: our definition of osmid is what OpenStreetMap call "OSM type and OSM id". It must start with an alphabetical representation of the type, then the numerical ID. Do not use placeid, which is visible in API calls - these are unique to each mirror of the OSM data.

UX suggestion for podcast hosts

The quality of this data is important to ensure a good listener experience. A podcast publisher should be in no doubt what data is being asked for here, to clarify that this is about a location that is mentioned in the podcast. The wording of this feature is important to ensure the correct data is available.

Podcast hosts may also wish to remind podcast publishers to always be cautious about posting public location information. It's possible to check the OSM type to see if it relates to a residential address.

Examples

For a podcast that is talking about the Eiffel Tower, (but actually made in Birmingham AL), this is what the specification would suggest:

<podcast:location
  name="Eiffel Tower, Paris"
  geo="geo:48.858093,2.294694"
  osmid="W5013364"
>

For a podcast that is set in Gitmo Nation, a nickname used by the show for the United States of America:

<podcast:location
  name="Gitmo Nation"
  geo="geo:39.7837304,-100.445882;u=3900000"
  osmid="R148838"
>

The geo point uses an optional 'uncertainty' value here of 3,900 km, indicating that the "location" described here is up to 3,900km away from the point given (which is the rough width of the USA). The OSMID includes a more accurate bounding box and geoJSON.

For a podcast that is about Hogwarts, a fictional location, geo and osmid must not be entered.

<podcast:location
  name="Hogwarts"
>

For a podcast from Tesla upon landing on Mars

<podcast:location
  name="Tesla Base 3"
  geo="geo:37.786971,-122.399677;crs=Mars-2031"
>

(The co-ordinate reference system from Mars doesn't yet exist, but this shows the extensibility of this tag).

What this tag isn't built for

For privacy and user experience, this tag is not meant as a description of the physical location of podcast hosts and guests ("I'm doing this podcast in Denver, Colorado!"). The physical location of people are available via the podcast:people tag's links to places like Twitter, Facebook, Wikipedia and Podchaser.

[jamescridland]

Questions from the above:

• should description actually be mandatory? How can we have no fields here which are actually mandatory other than "from/about"?
• is rel the correct descriptor?

Points to note:

The above post is edited to reflect the latest proposal, based on the discussion below. Some of the discussion below may reflect old versions of the proposal.

[kingreza]

I spent some time reading through the different proposals around the location tag. Thank you for unifying them under one. This will make the discussion much more focused.

Given the format above, would this be what we would expect for a location tag on a podcast that's about the Eiffel Tower?

<podcast:location rel="About Effiel Tower" description="Known as the most visited tourist attraction in Europe, the Eiffel Tower is considered one of the most recognizable and favorite landmarks of the modern world" geo="[geo:48.858093, 2.294694]" osmid="5013364">

if so I wonder if the description is a bit redundant? I would assume the details about the location if relevant to the podcast or chapter would already be covered in the podcast/chapter description.

In fact should the tag for from a location be the same as a tag for about a location? On the surface, it may seem natural to use the same tag and have a flag inside to indicate either but I can see that leading to confusion and inconsistent usage, as the two solve for different problems.

The more I look into this, the more I wonder if tags that are meant for general metadata should extend to include editorial content as well? or would this put us on a slippery slope of having <people rel='about'>, <timespan rel='about'> <color rel='about'>.

the editorial content of a podcast tends to be fluid and will most likely not fit into tags. I think if you make it too difficult for the person generating the tags to fit things nicely, the less likely it is for them to use it or use it correctly.

As an example, if the content of an episode is about let's say glass sculptures, and the host is interviewing an artist that briefly talks about his latest creation being inspired by the Eiffel tower, should that have a location tag with about Eiffel Tower? I don't think so, but why not? there would be no rule for or against it. It would be a difficult tag to fill.

Thoughts?

[jamescridland]

Good call for some examples - it would help. This is great feedback, thank you.

description is the name of the location. I will go and tighten up the top post to make that clear. Not a big long essay about it, but just its name. osmid in your example was wrong - it was missing the type. But that's cool to see. So...

Example

For a podcast that is talking about the Eiffel Tower, (but actually made in Birmingham AL), this is what the specification would suggest:

<podcast:location
  rel="about"
  description="Eiffel Tower, Paris"
  geo="geo:48.858093, 2.294694"
  osmid="W5013364"
>

(The OSM ID is from here).

In fact should the tag for from a location be the same as a tag for about a location?

I can absolutely see the rel= gets confusing. My fault entirely.

How about we use rel="subject" - the subject of this show is the Eiffel Tower rel="publisher" - the publisher of this show is based in the Eiffel Tower ...is that a bit clearer?

if the content of an episode is about let's say glass sculptures, and the host is interviewing an artist that briefly talks about his latest creation being inspired by the Eiffel tower, should that have a location tag [for the] Eiffel Tower?

Perhaps "subject" and "publisher" is clearer here. To my mind, this is a podcast about glass sculptures. The "subject" of this podcast is not the Eiffel Tower, and someone searching for podcasts about the Eiffel Tower wouldn't want to hear a podcast about glass sculptures. But if the podcast went off on a long tangent about the Eiffel Tower, then perhaps...

[swschilke]

I would still like to see a language tag here, in the case of #107 should be closed. A podcast can be from one country but be in another language. So such a tag is necessary (somewhere).

[swschilke]

About the location: Also, I would go with standards like an RFC, which osmid is rather not. Check out e.g., the NUTS Code (Nomenclature of Territorial Units for Statistics see at https://ted.europa.eu/TED/browse/browseByPD.do) which allows you a rather detailed description of a place.

[jamescridland]

In terms of language, you commented in #107 that "I can be from Germany but the podcast is in English"

The <language> tag already exists in the base RSS specification. So, your podcast's feed would read, in part:

<channel>
 <title>swschilke's podcast</title>
 <description>My podcast</description>
 <language>en</language>
 <podcast:location
   rel="from"
   description="Frankfurt, Germany"
   geo="geo:50.1106444,8.6820917"
   osmid="R62400"
 >
</channel>

Currently the RSS specification does not allow the "language" in an individual 'item'. Most multilingual podcasts out there appear to have separate feeds per language, since the amount of someone who speaks both English and German will be significantly lower than the amount of people who speak just one of those languages.

As you say, language is different from location, and I don't quite understand the benefit of the language being in a tag that is meant to discuss a location. Could you help me understand?

Alternatively, would you be happy to suggest an extended language tag to go into an 'item', if that's your intention?

[swschilke]

Dear James, the comment referred to comment in #107 to close it as there is #138. If you close #107 it should be reflected in #138, shouldn't it? I'm not sure if the language tag you mentioned is a really used "standard" (not even on channel level) as we saw in the discussion on Mastodon (mainly filled with English even for non-english podcasts). Would it harm to have it on episode level as well? Besides, there is only one tag as far as I understood it, so no multiple languages possible. Regards

[jamescridland]

@swschilke The language tag is a long-established part of the RSS specification. This is a set of graphs showing its use in podcasting. From this data, it seems well-supported.

I agree that no multiple language feeds are possible currently. As you say, "location" is nothing to do with "language", so I don't understand its place in a tag about locations. Could you help me understand?

In terms of location - you're absolutely right that part of the issue here is that there is no RFC for places: it's one of the reason that this has been made so difficult.

NUTS is is an EU-only system, and only goes down to municipalities (in Germany); so for Hamburg, all 1.7m inhabitants live in the same NUTS code. I'm not sure it does what we'd like it to - to describe the Elbe Philharmonic Hall (W24981342), or even the viewpoint on the west side of the hall (N4697038408) rather than the north side (N4510933902).

This is very useful feedback - if you do find other open systems to describe places it would be helpful.

[samsethi]

Great discussion. Thanks for putting it into one thread. Has anyone considered using ///what3words for location as that can be accurate to 3m anywhere on the planet and has the benefit of the location being permanent but the place being temporary

[swschilke]

@samsethi is that ///what3words an international "standard", I don't think so (as soon as they run out of money they are gone). You could also use the Google location’s Plus Code instead (Sample 5JFJ+97 Frankfurt )

[jamescridland]

@swschilke Would be very grateful for some alternatives. What would be super is to see if you can get the examples working, above, using a different system, to the same preciseness.

@samsethi Perhaps it's worthwhile being clearer here... so for the benefit of the discussion...

We have two requirements with a programmatic location description.

Requirement one: we need a permanent point reference

I'm suggesting this is defined by a geoURI, based on RFC 5870. This is built from a lat-lon - the most widely used method of pinpointing a place on Earth. A geoURI has the addition of an optional "uncertainty" factor, and an optional height-from-ground-level.

There are other ways, as you highlight. Frankfurt is described in geoURI form as geo:50.1106444,8.6820917, in ///what3words form as bangle.lock.slimy and in Google's Pluscodes as 4M6M+84 Frankfurt, Germany

All three are good - though it appears that lat-lon appears to have the widest adoption, and I think we'd be wise to use it.

However, the big problem here is that they actually don't reference "Frankfurt". They reference a small point on the ground in Frankfurt. The Pluscode above is the pluscode of the middle of the Frankfurter Kunstverein, an art museum. What3Words actually refers to a small square in the middle of the Braubachstrasse, close to the town hall. The latlon appears to be the south end of a building off Bethmannstrasse.

And that's fine. In every case, these point to somewhere in Frankfurt. A zoomed-out map will consistently be clear that it's in Frankfurt. But programmatically, we don't know whether the podcaster meant to refer to the art museum or the city as a whole. Hence requirement two.

Requirement two: we need a "thing" - a city, place, building or physical location. This helps anyone wanting to find an actual podcast about the art museum, rather than just Frankfurt.

Using OpenStreetMap IDs...

R62400 is Frankfurt, the city. Here's a picture of it, and you can see it's an irregular shape and contains quite a lot of things. The API says it's an administrative area, and defines it in GeoJSON.

N1851804853 is the Frankfurter Kunstverein. Here's where that is. In this case it's a 'node', a point on the map, but it's definitely a reference to the art museum, since the API also says that Its is a museum (in the tourism category) and that its address is "Frankfurter Kunstverein, 44, Markt, Innenstadt, Altstadt, Innenstadt 1, Frankfurt, Hesse, 60311, Germany".

There are other solutions for what I'm going to call "thing IDs". Geonames is a good database of places, but doesn't go down as far as individual buildings. It's a simpler system, and perhaps that's better, though I'm a bit unclear how you edit it. Google Maps have placeIDs, which are also great, though Google's API is paid-for and you are not allowed to cache the results. Wikipedia also has IDs for places, though I'm not very clear how they work. And I think Bing has some form of this too, along with others.

As noted at the top of this page, place IDs are not guaranteed to be permanent - while you can probably guarantee that Frankfurt will be there for many years to come, the Frankfurter Kunstverein may close, move, or collapse. So we need both a permanent point reference, since the place on Earth won't disappear, and a "thing ID" as well.

Although I'm a member of the OpenStreetMap Foundation, and have spent a long time mapping my local area on OpenStreetMap, I'm not wedded to using OSM IDs. Having looked quite hard at place names for a variety of reasons over the years, OSM seems the most sensible - but I'm very open to other systems to reference a "thing ID". OSM is licenced to use as long as you attribute it correctly, which seems sensible: but I'd be super-grateful for considered alternatives.

As an aside - the data held in an RSS feed, alongside an OSM lookup, would allow these use-cases:

• Show me podcasts about train stations in Germany
• Show me podcasts about Californian places in the Swedish language
• Show me podcasts from people in West Australia about mines

So, in short, my proposal is: a) latlons (in the form of a geoURI, which is extensible to other planets in time, as well as having a few additional concepts) seems most sensible for a "point" on Planet Earth b) "thing ID"s appear to be best served with an OSM ID, but I'd be happy to consider others

Hope all that is helpful! Keen to focus on this.

[benjaminbellamy]

@jamescridland I love that proposal.

a) latlon (WGS84) works everywhere: https://maps.google.com/maps/search/48.8576248,2.2942817 https://www.openstreetmap.org/search?query=48.8576248,2.2942817 https://maps.apple.com/?q=48.8576248,2.2942817

b) OSM is open, free, and it allows to specify a whole continent, a sea, a country, a town, a mountain or a local candy shop. And it is very easy to use thanks to https://nominatim.org/release-docs/develop/api/Overview/

[douglaskastle]

Still feel that startTime and duration attributes should be optional on the tag that goes in the RSS feed. If no ones uses it, no harm. Having to place it into a separate json file as the only way to use this, I feel, will impact adoption.

Note, I don't think the issue should have been closed, watch as the intent of what the issue was discussing will be completely lost for the remainder of this issue. Issues are meant to allow specific detailing of features, not throw them all into one balmanche. You can make issue dependent on other issue to link them but also separate out the conversation.

[jamescridland]

Thanks, @benjaminbellamy !

@douglaskastle I apologise for pulling things all together. It's my intention to ensure that this isn't kicked into phase 3 because it's all too complicated - and by having one discussion for this one tag, I hope to allow everyone to have their say, in one place, ensuring that we don't splinter into 400 different conversations. "Merged" might be a better word than "Closed". Apologies - I'm definitely trying to move this conversation on, and not trying to shut anyone down.

Certainly open to having timing detail in this tag. Let me understand how it works - if I'm doing a tour of Frankfurt, when I get round to the Frankfurter Kunstverein about 15 minutes into the podcast, I put the image and link into the chapter file, but the location tag into this separate tag in the RSS feed? I'm a little unsure of the intention and benefit here.

[douglaskastle]

@jamescridland This is a good example why issues are kept separate, I discussed and gave exactly the the example that you are requesting in the original issue:

https://github.com/Podcastindex-org/podcast-namespace/issues/114#issuecomment-727639278

Typically issues are boiled down to discrete problems that can be solved and closed. Maybe that is not how it is being used here, it is more like a forum discussion, which I am not sure if github issues is the best structure for that.

I can't comment on the image and link to the chapter file, other than to say why are the coupled? there may cases where the are co-incident, but that doesn't mean there needs to be an enforced dependency between the two.

The intention is first to aid search, there may be multiple locations per podcast, imagine a news show that has content covering more than one place (and that place may or may not be where the podcast is from). So based on the search the podcast can appear in multiple searches near the respective locations.

Don't get me wrong, it all can be pushed into a separate json file. I just know that the effort to implement that over the existing way of opening up the RSS tag space is probably an order of magnitude simpler, and this will have a trickle down on the adoption. This is of course just my opinion. However, in the presence of a JSON file, I think 3-5 tags maximum in the RSS feed, any thing beyond that should go into a separate JSON feed. This is similar to the person discussion whether a full cast list should be in the RSS feed or the show notes.

#96

I think there is some confusion about when and why a location tag should be used. Personally I think that a tag should only cover content, and only if the content relates to a place. If one records their podcast in Oz or Ireland for example (which I have) but never mentions any thing related to that, then is is not suitable to tag. That is a personal preference to be sure. Ultimately the market will decide and there will be many cases where people will tag a location, but the location will not refer to anything in the podcast itself, which of course is their prerogative.

However, when it comes back to the user experience of search, the person that searches for a podcast by location and clicks on one that is returned and then turns out to be nothing about that location, is a bad user experience for that user. I don't know the correct way to manage this other than to put out some suggested guidelines (which won't be read by the majority, but that is par for the course)

[daveajones]

Thank you for spending an obviously significant amount of time considering and typing all of this up James. I agree. Let's push this thing forward however we can.

My thinking is that what will drive this tag (90% of the time) is the UI on the podcaster's hosting company dashboard. That's where the rubber meets the road.

If the UI is presented this way:

...the result will be unpredictable, with most podcasters guessing at the intent.

On the other hand, if it's presented like this:

...it will encourage podcasters to enter the location that their podcast content is about.

What I'm getting at, is that the spec for this tag is going to be as much about wording and guidance as it is about the actual structure of the tag itself.

So, my current input would be:

 <podcast:location
   rel="from"
   description="Frankfurt, Germany"
   geo="geo:50.1106444,8.6820917"
   osmid="R62400"
 >

• description (required) - There just has to be something here, in the sense that we don't want to force apps and platforms to do heavy lifting(api calls) if they just want to show a location name in their UI.
• rel (optional-ish) can be made to default to "about" if not present, since that's what we're assuming will be the overwhelming use case. Otherwise it can be "from", or another moniker.
• geo (recommended)
• osmid (recommended)

...which would allow for this type of thing:

 <podcast:location
   description="The Space Needle in Seattle"
   geo="geo:47.620422,-122.349358"
 >

That's a very simple structure. And, it should be easy for most systems to capture and/or display. And, then we just focus on education and guidance in the spec wording, so that the intention of the tag is clearly defined.

[kilobit]

++ Thank you @jamescridland for consolidating all these notes and to everyone for the discussion.

Something that was dropped in the consolidation is the use of a 'type' attribute to describe the format of the location data that would be included in that particular tag.

The reason for this is similar to a 'rel' tag in that it allows future implementations to adapt the spec to their novel use cases without needing to update the spec.

For consistency, we would want to provide a definition for the common formats or relations that would be expected to by supported and we could recommend ways for clients to handle formats / relations that they don't understand.

This also aligns with how other specs of this type are designed.

So a specification might look something like:

<podcast:location
  rel="[relation]"
  type="[format]"
  description="[humanly readable description]"
  [attrs...]>[content]</podcast:location>

Where:

"relation" is an optional attribute describing the podcasts relationship to this location.  

Valid values include:
 - from:  The location from which the podcast was recorded.
 - about: When some portion of the podcast is chiefly related to the location.

An unspecified or unknown relation should be treated as a 'from' relation.

"format" described the type of location information that is provided.  

Valid location types include:
 - latlon: The geographic coordinates attribute encoded as latlon="[latitude,longitude]".
 - geo:    The RFC 5870 'Geo URI' encoding scheme encoded as geo="[geo uri]".
 - osmid: The Open Streetmap ID described in (...) encoded as osmid="[OSMID]"
 - ...

A format that is not understood by an implementation should be ignored.

"humanly readable description" - An optional hint for implementations to title the 
 location in a particular way.  The description SHOULD be used even in the event that 
 the location format is not understood.

Multiple location tags are permitted describing different aspects of the podcast, multiple 
hosts, etc.

Example:

This example describes a podcast that includes content about the Space Needle in Seattle
 specified in the Geo URI format.

<podcast:location
   rel="about"
   type="geo"
   description="The Space Needle in Seattle"
   geo="geo:47.620422,-122.349358"
 >

I hope that this makes sense.

It's not the details that I am particularly concerned with (ie which formats or relations) rather it's the structure that expands to support new cases that we don't yet understand and doesn't require data or formats that may be irrelevant to a particular podcast or implementation.

Thanks!

[kilobit]

Slight addendum... if there is a concern about muddying things with more locations tags, an option would be to define the type as a comma separated list of formats.

e.g.

<podcast:location
   rel="from"
   type="geo,osmid"
   description="Frankfurt, Germany"
   geo="geo:50.1106444,8.6820917"
   osmid="R62400"
 />

[daveajones]

I really do like the type attribute. But, the way it's currently being proposed:

 <podcast:location
   rel="from"
   description="Frankfurt, Germany"
   geo="geo:50.1106444,8.6820917"
   osmid="R62400"
 >

... seems to already encompass it silently. If the geo attribute is present, then assume the type was "geo". If geo and osmid are both present, assume the type is "geo,osmid". It's sort of inherent in the tag as it's built. If we have a list of valid types - something like:

1. geo
2. osmid
3. locality

... then parsers can just look for them in the recommended order and grab the one they know how to handle.

Chime in if I misunderstood something.

[kilobit]

Interesting... great argument, @daveajones I can see how that solves the problem implicitly.

I would still argue for the explicit 'type' - 2 reasons:

1. Some future location format might be more complex than a single attribute would allow, possibly including character data, sub-tags or who knows what.

2. From an implementation standpoint, if it was an application I was designing - I would prefer the strategy where you look at the required parameter, 'type', then invoke a particular handler to parse the format. With an explicit 'type' both strategies will work, without it, the implementation is forced to scan the attributes.

Thanks again!

[jamescridland]

This is all great feedback, and thank you for it all. My apologies for hamfistedly consolidating everything together, though I don't make apologies for wanting to get this tag back on track. It's a super-good one.

@davejones I absolutely agree that the implementation is the important thing. That sort of tool - with the right wording - makes sense in the example at the top, and I'll work to include that (with an OSM example, rather than a Google Maps one).

@douglaskastle and @davejones both make a good point, which Douglas is good at highlighting:

Personally I think that (the) tag should only cover content, and only if the content relates to a place.

The more that I work on this, the more that I agree with this. I can't think of a good user experience that is based on where a podcast is physically made, which wouldn't also be usefully answered by what a podcast is about. Podland, a podcast I make with Sam Sethi, would end up having a weird dual location requirement of being made in Marlow, England and in Brisbane, Queensland. The content isn't about either of that, though - so who cares where we're based? (And how would we fill it in anyway?)

And this isn't about where a podcast is based. It's about where podcasters are based. There's absolutely a use-case for "find podcasters near me", but that's about people, not shows. The people tag already links through to Podchaser, which is location-aware, so arguably we have a much better solution for human beings by using the 'people' tag.

Benefits of removing the rel attribute entirely, and for the podcast:location tag to only reference the subject of individual shows, allows simplification of the spec, and super-clear guidance given to podcast hosts.

So, a proposal: podcast:location is just about the editorial content of a podcast, rather than the location of where it's being made. Do we agree with this? Thoughts?

@douglaskastle - thanks, too, for engaging with the startTime/Duration data. I'm still unconvinced as to why this doesn't live alongside chapter information: it would seem much closer to that concept. I completely understand the benefit of keeping things simple for developers (remember when I was keen to ensure a country code in this tag? ;)) but in the use-case you give, it would benefit the search engine to be indexing all the chapter information anyway. Is this something we might encourage the chapter data to include?

@swschilke Are we good?

@kilobit I love the idea of keeping this tag flexible. @daveajones's suggestion is, I think, helpful - none of this is cast in stone forever, and backwards-compatible changes are always possible. Both the geoURI and the osmid attribute is built from two or more elements, in fact, and I think if we were to add additional types in the future they could be accommodated in this way. I'm also quite keen that both geoURI and osmid are always used in the case of a real physical location - the power of the osmid tag is astonishing in the right hands: and anything that communicates to publishers that they can just drop the osmid tag would have a serious detriment to user experience. In short, my ideal would be that type is always set to 'geo,osmid'.

Finally, for all here - https://maps.fm might give us a glimpse into the future. The team here have done a great, manual, job at highlighting geo-information about individual podcasts. I'm super-excited at getting this tag into the spec - as long as it offers a great user experience and is programmatic and detailed.

[kilobit]

Thank you and well put @jamescridland.

For my part of your comments, the question for both 'rel' and 'type' comes down to the purpose of the spec:

Option 1 - Directing podcasters, app developers and service providers to create a platform adopting a prior set of features and approaches.

Option 2 - Providing a mechanism for describing podcasts that podcasters, app developers and service providers can use to implement features they would like to see.

For example osmid - it seems like a very tight coupling to a spec that is controlled by a single organisation. I reserve the right to be completely wrong about it ( :) ) and I see absolutely no problem with recommending it in the spec, but the spec designer in me does feel squidgy at the prospect of it being required.

So, I prefer the Option 2, but it is okay if the purpose of the spec is Option 1.

Cheers!

[jamescridland]

@kilobit Thank you, that's helpful.

I agree that it's sub-optimal to be coupling to a spec controlled by someone else (although, you know, this is a namespace for the RSS spec which is nominally controlled by someone else). I think concerns are mitigated by the fact that OSM is open, all the data is downloadable, and it's run by a Foundation which is membership-driven. The amount of data held in OSM can be very deep, and would lend itself to many interesting use-cases (which, sadly, we can't say about a lat-lon point). It's also intended to be used alongside a geoURI, for the explicit reasons that geoURIs will always exist, while places/things will not.

(But - if there's a better alternative for "places and things" than OSM, I'd love to know.)

I think that the tag spec as it currently exists is flexible enough to do both options - to fulful a suggested UX featureset, but to also leave it open to the future. Should we decide to also use eggScores to define a location, we can add an eggscores attribute at some point in the future. (To save you looking - there's no such thing.) With something as complex as this, I think that someone has to make a decision as to where we go first, though. As Dave's said, I think the presence of an additional 'type' attribute is implicit in what attributes are present - I appreciate your point of view that there's benefits to be explicit here, but I'm wondering whether simplicity of implementation is more important here. We can make this tag as complex as we like, but if nobody uses it, we'll have failed.

I'd like to be able to suggest that we add a rel attribute back in at some point in the future if there is a good use-case for it; but that our suggestion is for now that rel always defaults to about, but that its declaration may be required for other use-cases in future. The more I write about it, the more it seems that from is really only relevant to people or publishers, and not 'podcasts'.

[jamescridland]

@daveajones I've added the map UX example that you gave to the proposal at the top of this page.

[kilobit]

My apologies, I regret including the 'osmid' example, I think it has distracted from my point.

The part I am interested in is this:

Option 1 - Directing podcasters, app developers and service providers to create a platform adopting a prior set of features and approaches.

Option 2 - Providing a mechanism for describing podcasts that podcasters, app developers and service providers can use to implement features they would like to see.

Hopefully it's a bit clearer this way. I will leave it to you (@jamescridland) and @daveajones to sort out.

Thanks!

[swschilke]

@jamescridland thank you - I think there are two locations, some are detailed and some are more on a birds-eye view level.

The podcaster wants you to know his country, region, or maybe even the city. To prevent doxing I wouldn't go deeper.

The episode or content (especially in history, travel, etc. podcasts): wants to have a detailed location or even a list/track of locations.

Just my two Pfennig 😉

[jamescridland]

@swschilke Two use-cases here, absolutely.

"The podcaster wants you to know his country, region, or maybe even the city." - I think I'm now proposing that this use of podcast:location is actually better supported by rich data via podcast:people. It's the location of the PERSON DOING THE PODCAST, not the location of the "podcast". I'm asking for feedback on removing that from this specification, and thus simplifying and clarifying it.

"The episode or content wants to have a detailed location" - yes, indeed. I see this as the primary use-case for this tag.

Thank you!

[daveajones]

So, a proposal: podcast:location is just about the editorial content of a podcast, rather than the location of where it's being made. Do we agree with this? Thoughts?

I agree fully with this.

[jamescridland]

I've amended post #1 here. The changes are, for your feedback:

1. Removing the rel="about|from" construction. This tag is exclusively to discuss locations in podcasts, not physical locations of hosts and guests. This is following @douglaskastle's feedback and that of others.
2. Changing description to name to clarify what's expected here. If @kingreza was confused, other people will be.
3. Giving additional use-cases, noting the relationship to <language>, which @swschilke is right to highlight.
4. Pointing out as many times as I can that ideally geo and osmid go together (!) - though there may be relevant reasons why this isn't in 100% of cases.
5. Links to OSM and explanation of its features.

Would be super-grateful for feedback. I think we've significantly simplified this specification, and made it much clearer as to its purpose.

[benjaminbellamy]

Here is my personal feedback: this looks perfect to me. Thank you!

[daveajones]

Would be super-grateful for feedback. I think we've significantly simplified this specification, and made it much clearer as to its purpose.

This looks great James. I've looked over it a few times today and I can't find anything wrong with it. There is a lot of flexibility here to go from simple, hand written up to complex API driven.

I think I will put in some preliminary code in our aggregators to pull this in and just see how the code feels.

[benjaminbellamy]

I will start adding that to Castopod to see how it looks.

[wturrell]

+1 for what @swschilke said about location support at episode level. From a listener's point of view, consider how useful it would be to search for a location and jump to the specific podcast episode relevant to it (e.g. documentaries on international broadcasters like BBC World Service, or a travel podcast covering a different country/city each week)

[douglaskastle]

+1 for what @swschilke said about location support at episode level. From a listener's point of view, consider how useful it would be to search for a location and jump to the specific podcast episode relevant to it (e.g. documentaries on international broadcasters like BBC World Service, or a travel podcast covering a different country/city each week)

@wturrell Or even straight into the middle of the podcast, and there may be more than one topic and the locations may be completely different.

[jamescridland]

@wturrell Agreed. This is in the spec - the podcast:location element can be either a channel element ("about the podcast") or an item element ("about an episode"). In both cases, you can have multiple elements, so a podcast about ugly steel towers can include both W213940301 and W5013364 (wink).

[cio-blubrry]

Hi everyone, great work on the phase 1 namespace!

I don't see it mentioned in this thread but this is similar to the rawvoice:location namespace we created 10+ years ago. We went down a similar path, trying to figure out what meta information to include with location, it is interesting to see history repeat itself. We opted to let the user freeform what they wanted to disclose for their location, at the time the use cases we had we simply wanted to display the major city, region/state/province and possibly country in our website and TV apps. I think there are some interesting uses for osmid and geo meta data, but I am also concerned about privacy when implemented poorly. I am excited to see how this pans out.

Thanks, Angelo

[jamescridland]

Thanks, Angelo! Yes, I spotted the rawvoice:location tag. I think we've emulated that in the name portion of this specification, to allow the user to freeform.

I was quite concerned about privacy, too - thankfully, podcast:location is explicitly not anything to do with a podcaster's location - but the subject of the podcast instead. This isn't about the people who are podcasting.

However, I wonder if it should be clear in the spec (and therefore clear in any implementation) that a podcast:location is always public, and care should be taken when linking to a place? That might be a good call. A podcast host could also potentially reject housing OSMIDs - homes and housing have specific building types which could theoretically be blocked from being added here. But that might be something for podcast hosts. That might be worthwhile writing into the (already too long) spec?

[jamescridland]

...and, @cio-blubrry , I've added that little bit to the spec. Good call.

[cio-blubrry]

I would keep things as you have it, but I know at some point a service is goin to make it easy by using the location where the person just uploaded or recorded the podcast as the podcast:location and then privacy is compromised. We can put all the warnings you can think of here and it will not stop someone making a podcast service from thinking they have a great idea "lets use the geo location where they upload" and what you wanted to avoid happens.

[daveajones]

@jamescridland Do you think we're good to move this back into the README as a baseline?

[jamescridland]

@daveajones I think we're good for that.

[jamescridland]

Here is an image of Open Street Map which I intend to put in the documentation. I need to upload it here, oddly. So here it is.

[jamescridland]

And here's another.

[cio-blubrry]

Forgive me, perhaps this has been asked in the past, but many situations in the RSS spec where the label or displayed text for a tag like this is put in an attribute=value instead of being the actual value of the tag itself.

e.g. <podcast:location name="[humanly readable place name]" (geo="[geoURI]") (osmid="[OSM type][OSM id]") />

When following XML practices would be <podcast:location (geo="[geoURI]") (osmid="[OSM type][OSM id]")>[humanly readable place name]</podcast:location>

I see this with the and , where as is using the value of the tag rather than attributes.

Last thought, if you want to keep the actual displayable label/title for a tag, apply some consistency across all of the tags. I would recommend using the HTML5 attribute "title" specifically, as it is meant for screen readers and such, it is a good indicator for someone who looks at the XML that this is what you can display to the user. and instead of using name/display would both use title="". Another idea if "title" rubs folks the wrong way is to use label="". I would though prefer consistency and label be in the value rather than an attribute.

Benefit doing this would be for an XSL Template to be able to consistently pull viewable information easily, hence the readable value being the tag's value rather than it found in an attribute.

[daveajones]

This (text as node value vs. attribute) has been bounced around in a few of the closed issues before, and it seemed like most people thought it better to have in the attributes. It seemed more XML'ish to them. I lean more towards the node value, but I relented and went with attributes.

I think some of the inconsistency with that stems from trying to co-exist. Like <podcast:episode> is trying not to stray too far from <itunes:episode>, since we were kind of forced into that one.

I would like to go through and check for attribute name consistency before formalizing phase 2. Thanks for bringing that up.

[jamescridland]

Thanks, Angelo - I have no preference either way, and would be happy to go with whatever is best.

@dave - Upon reading the OSM data again, I'd like to suggest that osmid="[OSM type][OSM id]" becomes, optionally, osmid="[OSM type][OSM id]#[OSM revision]" - when the hash is not present this refers to the latest revision of the OSM type and ID, and when present, refers to that precise revision.

This allows for all the data fields for a potential permanent ID referred to at the bottom of this: https://wiki.openstreetmap.org/wiki/Permanent_ID - and particularly would allow a podcaster to, if they wanted to, refer specifically to "this building before the fire" or "this park when it re-opened", or "this pub before it became an Indian takeaway".

What are your thoughts?

On a second thought - while we can, is it worth renaming this field to be simply "osm=" rather than "osmid"? It strikes me that we shouldnt be calling it an OSM ID when it isn't actually the ID.

[daveajones]

I think all of that is fine James. We only have 2 apps currently implementing to my knowledge. So, I can just communicate that attribute name change to them. I'll make all of these tweaks tonight.

[cio-blubrry]

I would recommend the value being in the tag rather than in an attribute when the case can be made that the information is readable and could be displayed using an XSL Template.

[daveajones]

I would recommend the value being in the tag rather than in an attribute when the case can be made that the information is readable and could be displayed using an XSL Template.

Which value? The place name string?

[cio-blubrry]

The text that should be displayed.

e.g. <podcast:location rel="from" type="geo,osmid" description="Frankfurt, Germany" geo="geo:50.1106444,8.6820917" osmid="R62400" />

would be `<podcast:location rel="from" type="geo,osmid" description="Frankfurt, Germany" geo="geo:50.1106444,8.6820917" osmid="R62400"

Frankfurt, Germany</podcast:location>`

I keep going back to XSL template but when viewing an XML document I always think about it as an HTML page, what is readable that you would display to the user would go in the VALUE and attributes provide additional readable and non readable information. In the case that a tag does not have anything readable the VALUE is empty. I will use HTML, the king of all XML, as an example..

<title>Title of page</title> <meta charset="UTF-8" /> <p class="name">This is a paragraph</p> <a href="https://google.com" title="Click this link to search google">Google</a>

For others reading this who want a refresher on XML tags, the entire thing we are addressing is called a TAG., the tag "VALUE" is found within opening and closing, attributes are name="value" pairs found in the initial opening tag. e.g. VALUE.

Is there something readable/scannable in this particular tag and I would say yes. The other day I was thinking in terms of the feed being viewed in a browser styled by an XSL Template, today I am also thinking about the information being scanned and indexed for search purposes, one would want to see the readable value in this scenario in the VALUE portion of the tag.