Are there any Fediverse application that have problems receiving objects that have arrays within the "type"? @MastodonEngineering

André Menrath

But one could implement simple fallbacks, like if it is an array take the first item, if it is not known to you take the next one.

silverpill

@grindhold @dansup @helge @pfefferle @linos @laurin @MastodonEngineering @mkljczk Yes, unfortunately this is in the specs: https://www.w3.org/TR/activitystreams-core/#fig-an-object-that-is-both-a-place-and-a-gr-location
In practice multi-typing is totally useless and hinders interoperability, so all ActivityPub projects assign a single type to their objects.

André Menrath

@silverpill

I think there are good examples, where it might be useful.

E.g. take an Event. You have the location, but it is online. So you don't add a Place, but rather an schema.org/VirtualLocation. It also has a Name and a URL. If you also give it the type Place applications that do not know about VirtualLocation can still receive it.

I am just about finishing a FEP draft. I hope I don't miss something! I'd say let's keep discussing on socialhub once it's submitted?!

Helge

Using something like

{
  "type": "Place",
  "tag": [{"type": "gr:Location", ...}, ...], ...
}

would be better. None of the issues with multityping, and everyone knows which attribute is of the Place and which is of the Location.

Multityping could make sense. However, just as multiclassing is both useful and hard to implement and explain correctly, so is multityping. And AFAIK with json-ld / AS the work has not been done yet.

André Menrath

@helge @silverpill I more and more start to see JSON-LD as a mere reminder for devs that we think about stuff carefully. But the most real world Fediverse just uses compacted JSON, an there your approach might fail, or not?

Or could you extend your example, not sire I am getting it right.

silverpill

@linos Generally, applications should look for properties they understand, and ignore object types. This practice is known as duck typing. In case of location you can parse name and optionally coordinates. Now your peers can use any type they want, or skip it altogether - as long as name is present you will have something to work with.

silverpill

@helge @linos Good idea.
Inclusion of a new property is usually a safe operation, compatibility with other software is preserved. Change of type often breaks something

silverpill

@linos

WIP: Initial Draft of FEP-8a8e: A common approach to using the Event object type

fep - Fediverse Enhancement Proposals

Codeberg.org (codeberg.org)

>Or use a custom attribute https://event-federation.eu/ns/#isVirtualLocation

+1

I think boolean attribute is cleaner than multi-typing. You can also duck-type location as a virtual location if url attribute is present

Laurin

@silverpill @linos
I see the point about compatibility with apps that do not follow the spec here.
Why would you say, it is cleaner though, to add a property only, over adding a second type?

For both cases: If I wanted to be thorough, I'd go and add this property to an RDF ontology. I'd expect the ontology to define that type and the property associated with it.
So in the end, it'd be a multi-type along with a definition of the property that is linking to a video, for example.

silverpill

@laurin @linos
isVirtualLocation is self explanatory. [Place, VirtualLocation] is not - is it "Place and VirtualLocation", "Place or VirtualLocation", something else?

More importantly, no one in Fediverse uses multi-typing, we use properties to extend standard objects. Introduction of multi-typing creates a lot of work for everyone.