Are there any Fediverse application that have problems receiving objects that have arrays within the "type"? @MastodonEngineering
-
@grindhold @linos @MastodonEngineering @dansup @pfefferle @helge @mkljczk @laurin
https://www.w3.org/TR/activitypub/#:~:text=If%20you%20don't,plain%20old%20simple%20JSON. is a bit dishonest here. AP has to decide, either the complexity of json-ld ontology algebra or the simplicity of plain old json.Currently the advertisement says 'simple' while the reality is 'complex' and can break existing (simple) implementations at any time.
AP can't be both.
-
André Menrathreplied to Marcus Rohrmoser 🌻 last edited by
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.
-
@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é Menrathreplied to silverpill last edited by [email protected]
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?!
-
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é Menrathreplied to Helge last edited by [email protected]
@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.
-
@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 parsename
and optionally coordinates. Now your peers can use any type they want, or skip it altogether - as long asname
is present you will have something to work with. -
-
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 ifurl
attribute is present -
@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. -
@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.