How to represent Places in an event

Software Mobilizon
1

ActivityStreams vocabulary says about Places:

The Place object is intentionally flexible. It can, for instance, be used to identify a location simply by name […] or, by longitude and latitude […]

While publishers are not required to use these specific properties and MAY make use of other mechanisms for describing locations, consuming implementations that support the Place object MUST support the use of these properties.

For instance, Honk seems to use this.

"location": {
    "latitude": 39.95,
    "longitude": -75.17,
    "name": "Joe Rittenhouse",
    "type": "Place"
  },

In that specific case Mobilizon needs to specify address data (street, locality, …) which are not covered by basic AS Place type. Mobilizon replaces AS Place type with Schema.org Place type (and specifies it in @context).

"location": {
    "address": {
      "addressCountry": "France",
      "addressLocality": "Lyon",
      "addressRegion": "Auvergne-Rhône-Alpes",
      "postalCode": "69007",
      "streetAddress": "10 Rue Jangot",
      "type": "PostalAddress"
    },
    "geo": {
      "latitude": 4.8425657,
      "longitude": 45.7517141,
      "type": "GeoCoordinates"
    },
    "id": "http://mobilizon2.com/address/bdf7fb53-7177-46f3-8fb3-93c25a802522",
    "name": "10 Rue Jangot",
    "type": "Place"
  },

However, it might not be the best way. Maybe adding needed Schema.org Place properties (in our case: address) on top of the AS Place type is better. It would at least allow implementations that don’t support everything to grab a subset of the data, such as geographic coordinates for instance.

What do you think ?

2 Likes
2

So I’m implementing this for a Radar version just at the moment. Webfinger sorted. The Activity Event formatting at the moment.

As people might know Radar has the structured addresses like Mobilizon is producing already in the API. One of the stumbling blocks with importing iCal feeds has been getting structured addresses out of the location field in iCal. Even when a system actually has that data we still have to parse the string that they put into the field into Nominatim to get a structured version back.

If a site doesn’t have a structured address they can just put the data into ‘location’: { ‘name’ and we’re where we were before.

But if sites have already got this data I’d love it to be made available, and we aren’t loosing this very valuable metadata.

3

The Place object in AS2 “represents a logical or physical location”, is a ActivityStreams2 object with additional properties:

  • accuracy, a percentage of the accuracy of positions coordinates (which sounds very abstract and not much actionable)
  • altitude in units, defaulting to meters
  • latitude
  • longitude
  • radius, defines an area around latitude and longitude, expressed in units (default: meter)
  • units

Latitude (φ) and Longitude (λ) are left without much definition. do not define any amount of precision: for INCOMMON, the chosen precision is 7 points after the comma, which amounts to 10cm at worst for all locations on Earth using the standard WGS84 Web Mercator projection used in most mapping software.

In Schema.org, the Thing properties latitude and longitude use WGS84 floats, but again, without a mandatory precision. That said, @tcit, the Place object can host both values without a geo attribute, and so match AS2, so you could as well drop the geo and have:

"location": {
    "address": {
      "addressCountry": "France",
      "addressLocality": "Lyon",
      "addressRegion": "Auvergne-Rhône-Alpes",
      "postalCode": "69007",
      "streetAddress": "10 Rue Jangot",
      "type": "PostalAddress"
    },
    "latitude": 4.8425657,
    "longitude": 45.7517141,
    "id": "http://mobilizon2.com/address/bdf7fb53-7177-46f3-8fb3-93c25a802522",
    "name": "10 Rue Jangot",
    "type": "Place"
  },
1 Like
4

@ekes what’s the iCal version looking like?

5

Yes, this was indeed what I was saying by:

It can be easily done in our case (MR is already ready :stuck_out_tongue:) , but I would like to have @les opinion for Gancio and @tedu for Honk (and maybe people from GetTogether).

1 Like
6

Well this version definitely looks better to me, I think it’s better to use ActivityStreams as much as possible for good interoperability, maybe have some text to describe data (so location.name should probably be a full representation of the postal address) but avoid extensions (mastodon fields are probably a good example of widely used extensions that are supported only on few softwares).

Also might be a good idea to ping Friendica folks on this, I don’t think they added as:Event support yet but they do have events support.
EDIT: friendica have events in AP as well: ActivityPub at 36C3 – the "!decentral" assembly and fediverse.party

1 Like
7

I absolutely agree, let’s take this way.

2 Likes
8

This is in part a follow-up to above and in part a reply to heluecht from another thread because it makes more sense here.

This is what I have in an outbox (part sample, and some things I’m still doubting, some json formatting might be broken too from the cut, snip, paste, and formatting here). Anyway now looks like:-

"@context": [
  "https://www.w3.org/ns/activitystreams",
  "https://w3id.org/security/v1",
{
  "xsd": "http://www.w3.org/2001/XMLSchema#",
  "schema": "http://schema.org#",
  "uuid": "schema:identifier",
  "PostalAddress": "schema:PostalAddress",
  "tzid": {
    "@id": "https://data.iana.org/time-zones",
    "@type": "xsd:string"
  },
  "rrule": {
    "@id": "ical:rrule",
    "@type": "xsd:string"
  },
  "ical:status": {
    "@type": "xsd:string"
  }
}
],

…

{
  "id": http://radar.example.com/activity/1), 
  "uuid": "bf425993-0e1a-40dc-bfaf-1c2221d36124", 
  "type": "Create", 
  "actor": http://radar.example.com/activity/group/41),
  "published": "2019-12-17T18:52:00+01:00", 
  "to": [
    https://www.w3.org/ns/activitystreams#Public
  ],
  "summary": "Benefit voku for Kobani II, Volkseten Vegazulu : 2016-01-26 19:00", 
  "object": {
    "type": "Event",
    "name": "Benefit voku for Kobani II, Volkseten Vegazulu",
    "id": http://radar.example.com/activity/node/4672),
    "uuid": "bcbbe3fa-ebe5-4498-9e4e-c607cc2f7583", 
    "url": {
      "type": "Link",
      "href": http://radar.example.com/en/event/amsterdam/joes-garage/2015-01-26/benefit-voku-kobani-ii-volkseten-vegazulu, 
      "mediaType": "text/html"
    },
    "startTime": "2015-01-26T9:00:00+0100",
    "endTime": "2015-01-26T3:55:00+0100",
    "tzid": "Europe/Amsterdam",
    "published": "2015-01-15T21:48:35+01:00",
    "updated": "2019-12-21T22:01:33+01:00",
    "content": "<p><strong>Monday January 26th 2015, Benefit voku for Kobani II, Volkseten Vegazulu, 7pm</strong></p>\n<p>Dear friends, .... </p>\n",
    "ical:status": "confirmed",
    "tag": [
      {
        "id": http://radar.d7.montseny.iskranet/en/taxonomy/term/6, 
         "name": "food"

…

    "location": [
      {
        "type": "Place", 
        "id": http://radar.example.com/en/location/2097,
        "uuid": "22c11074-2477-4a49-9564-e0064bc640e2",
        "name": "Joe&#039;s Garage Pretoriusstraat 43 Amsterdam Netherlands",
        "latitude": "52.355578000000",
        "longitude": "4.924975000000",
        "address": {
          "@type": "PostalAddress",
          "streetAddress": "Joe&#039;s Garage, Pretoriusstraat 43",
          "postalCode": "1092 EZ",
          "addressRegion": "Amsterdam",
        "addressCountry": "NL"
      }
  },

…