the first thing you need to accept in an open world is that people will say and do different things.
Uncategorized
13
Posts
1
Posters
0
Views
-
the first thing you need to accept in an open world is that people will say and do different things. if you operate under the assumption that everyone shares the same understanding you will quickly have problems. but rather than trying to get everyone to say and do the same things, you should instead be able to establish *equivalences*. you don't all say the same thing, but you recognize that the same thing might be said in different ways, and you have to translate the meaning across contexts.
-
the first thing you need to accept in an open world is that people will say and do different things. if you operate under the assumption that everyone shares the same understanding you will quickly have problems. but rather than trying to get everyone to say and do the same things, you should instead be able to establish *equivalences*. you don't all say the same thing, but you recognize that the same thing might be said in different ways, and you have to translate the meaning across contexts.
if you try to make everyone say the same things, you actually make the problem worse, because people are going to end up saying the same thing but with different meanings. you get consistent vocabulary but inconsistent meaning. this is otherwise known as ambiguity or equivocation.
-
if you try to make everyone say the same things, you actually make the problem worse, because people are going to end up saying the same thing but with different meanings. you get consistent vocabulary but inconsistent meaning. this is otherwise known as ambiguity or equivocation.
this is basically what happened with activitystreams as it gets used in fedi. the terms are defined by the w3c, but softwares don't use those definitions strictly. they have local concepts and abstractions, then they try to use whichever as2 term they feel is suitable. the mistake is assuming everyone else will inverse-map the as2 term to the same local concept or abstraction.
it would be better to just be explicit and describe/define your own local concepts instead of enforcing a lingua franca
-
this is basically what happened with activitystreams as it gets used in fedi. the terms are defined by the w3c, but softwares don't use those definitions strictly. they have local concepts and abstractions, then they try to use whichever as2 term they feel is suitable. the mistake is assuming everyone else will inverse-map the as2 term to the same local concept or abstraction.
it would be better to just be explicit and describe/define your own local concepts instead of enforcing a lingua franca
example: mastodon maps its Status to as:Note and its Account to as:Person or as:Service. what if it didn't strictly need to? when federating with another mastodon-like processor, the translation is unnecessary; when federating with a processor with a divergent interpretation, it can even be incorrect. what mastodon wants to know is if the Thing is a Status, but it can only be told the Thing is a Note. this makes it impossible to have a Note that isn't a Status, or a Status that isn't a Note.
-
example: mastodon maps its Status to as:Note and its Account to as:Person or as:Service. what if it didn't strictly need to? when federating with another mastodon-like processor, the translation is unnecessary; when federating with a processor with a divergent interpretation, it can even be incorrect. what mastodon wants to know is if the Thing is a Status, but it can only be told the Thing is a Note. this makes it impossible to have a Note that isn't a Status, or a Status that isn't a Note.
if mastodon had its own defined processing model that looked for its own defined terms (or their equivalents!) then this would be less of an issue. the problem with activitystreams is that its intended processing model is a) not formally defined/described in the spec, b) fundamentally different than mastodon's processing model.
activitystreams actually made more sense as an extension to atom, because in that case you are basically saying that a Thing is both an atom:entry and an as:Activity.
-
if mastodon had its own defined processing model that looked for its own defined terms (or their equivalents!) then this would be less of an issue. the problem with activitystreams is that its intended processing model is a) not formally defined/described in the spec, b) fundamentally different than mastodon's processing model.
activitystreams actually made more sense as an extension to atom, because in that case you are basically saying that a Thing is both an atom:entry and an as:Activity.
your typical atom processor could understand the atom:feed and look at each atom:entry for its atom:content. but your activitystreams 1.0 processor could look for the activity:verb and activity:actor and so on. the two processing models can exist side by side in the same document. the same document can be read in different ways by looking for different terms. maybe some terms have the same value across different contexts, but are you expected to know that upfront, or told that explicitly?
-
your typical atom processor could understand the atom:feed and look at each atom:entry for its atom:content. but your activitystreams 1.0 processor could look for the activity:verb and activity:actor and so on. the two processing models can exist side by side in the same document. the same document can be read in different ways by looking for different terms. maybe some terms have the same value across different contexts, but are you expected to know that upfront, or told that explicitly?
imagine how bad it would be if as1 was specified to reuse atom vocabulary but with different meanings. you'd never be able to tell if an atom feed was an atom feed or an activity stream! you'd just run into unexpected values randomly.
now, to some extent, these kinds of processing models and data models and semantics are typically part of the iana media type or http content-type. application/atom+xml isn't the same as a hypothetical application/as1+xml. but documents can only have one such type
-
imagine how bad it would be if as1 was specified to reuse atom vocabulary but with different meanings. you'd never be able to tell if an atom feed was an atom feed or an activity stream! you'd just run into unexpected values randomly.
now, to some extent, these kinds of processing models and data models and semantics are typically part of the iana media type or http content-type. application/atom+xml isn't the same as a hypothetical application/as1+xml. but documents can only have one such type
in http the content type can be negotiated with the Accept header, but when you do this kind of content negotiation, you aren't just negotiating the serialization or data format. you are also negotiating a processing model! otherwise, we would just serve everything as plain old application/json or application/xml or text/plain. these "less specific" types are relatively unconstrained on what you can do with them; they make no assumptions beyond "you will parse this with a generic processor"
-
in http the content type can be negotiated with the Accept header, but when you do this kind of content negotiation, you aren't just negotiating the serialization or data format. you are also negotiating a processing model! otherwise, we would just serve everything as plain old application/json or application/xml or text/plain. these "less specific" types are relatively unconstrained on what you can do with them; they make no assumptions beyond "you will parse this with a generic processor"
more specific types will further constrain your processing model or semantics:
- application/octet-stream might open in a hex editor
- text/plain opens in a text editor
- application/json is loaded into a json processor
- application/activity+json is loaded into an activity processor, and also defines what terms like "actor" and "object" mean in the first place. you know that "actor" means "who performed an activity" and not "who performed a role in a movie". -
more specific types will further constrain your processing model or semantics:
- application/octet-stream might open in a hex editor
- text/plain opens in a text editor
- application/json is loaded into a json processor
- application/activity+json is loaded into an activity processor, and also defines what terms like "actor" and "object" mean in the first place. you know that "actor" means "who performed an activity" and not "who performed a role in a movie".now, here's the exercise left for the reader: how do you signal that you want to process a mastodon status?
as a hint, consider a similar question that can be asked about atom and as1. how do you request an activity stream in as1? in that case, the same document might be served for both negotiated types (atom and as1). is this possible for heterogeneous fedi processing models?
-
now, here's the exercise left for the reader: how do you signal that you want to process a mastodon status?
as a hint, consider a similar question that can be asked about atom and as1. how do you request an activity stream in as1? in that case, the same document might be served for both negotiated types (atom and as1). is this possible for heterogeneous fedi processing models?
well, my answer is, there are two ways to do this:
1) everyone agrees ahead of time on what words should mean and what should be done. (this is turning the open world into a closed world.)
2) everyone uses their own words but tries to understand the words of others. over time, equivalences are mapped, and models can evolve and perhaps converge or diverge as appropriate.
-
well, my answer is, there are two ways to do this:
1) everyone agrees ahead of time on what words should mean and what should be done. (this is turning the open world into a closed world.)
2) everyone uses their own words but tries to understand the words of others. over time, equivalences are mapped, and models can evolve and perhaps converge or diverge as appropriate.
i think the missing infrastructure that makes people lean more toward 1 than 2, is that we don't have minimally-agreed-upon ways to do that kind of equivalence mapping. you have to obtain that knowledge out-of-band. the iana won't tell you which types are equivalent, and http generally won't let you say that some resource can be processed in multiple ways, and filesystems rely too much on file extensions to handle this gracefully.
-
i think the missing infrastructure that makes people lean more toward 1 than 2, is that we don't have minimally-agreed-upon ways to do that kind of equivalence mapping. you have to obtain that knowledge out-of-band. the iana won't tell you which types are equivalent, and http generally won't let you say that some resource can be processed in multiple ways, and filesystems rely too much on file extensions to handle this gracefully.
right now, this kind of equivalence information is hardcoded into the codebases of each fedi software. if you want to understand it, you have to go reading each and every codebase you care to interoperate with. that is the source of truth. there might be some html or markdown documentation available, but it is not a source of truth.
and of course, these fedi softwares just assume a whole lot of things that can't be safely assumed.
what if they didn't have to assume?
/thread
-
undefined oblomov@sociale.network shared this topic on
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
RE: https://mastodon.social/@quotidianopiem/116038466930856724
Era febbraio di 25 anni e anche allora eravamo nel Sud Piemonte. Erika e Omar uccidono madre e fratello di lei e agli inquirenti dichiarano che sono stati "gli albanesi". GiĂ allora c'erano politici che si facevano eleggere fomentando il razzismo e poveri fessi che andavano loro dietro
-
L’IA, il cosa e il come
SarĂ vero che dobbiamo ormai focalizzarci sul cosa fare e non sul come farlo?
-
@rotopenguin 🤣
-
@EdCates JC knows a real messiah when he sees one
-
-
Current* conditions near Sandy Creek, NY:
-
L'intelligenza artificiale rende la parte facile piĂą facile e quella difficile piĂą difficile
Un mio amico ha recentemente partecipato a un dibattito pubblico su come le organizzazioni di ingegneria possano supportare al meglio i propri ingegneri. I temi emersi non sono stati una sorpresa:
Sacrificare la qualitĂ rende difficile sentirsi orgogliosi del proprio lavoro. Nessun riconoscimento della velocitĂ attuale. Se corriamo per raggiungere un obiettivo, l'aspettativa diventa quella di continuare a correre, per sempre.
-
Almeno sei campi scientifici hanno scoperto in modo indipendente la stessa matematica
La stessa #matematica prevede crolli del mercato, blackout della rete elettrica, insufficienze cardiache e collasso dell'ecosistema. Almeno sei campi scientifici lo hanno scoperto in modo indipendente. La maggior parte non sapeva nulla degli altri. Ci sono voluti novant'anni perché qualcuno se ne accorgesse.
