Christopher Lemmer Webber is a user on octodon.social. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

I think the biggest challenge people are having with ActivityPub is that they are, for the first time, generally encountering a "structured open world system" for the first time.

Christopher Lemmer Webber @cwebber
Follow

Closed world systems let you control (and prove) a lot, but you can only do the things your own "world" has built an idea up about. Also "easier" to build DB schemas for, etc. But hopeless for extensibility when talking with the rest of the world.

Meanwhile, completely free-for-all-json, coordinating on meaning is nigh impossible.

· Web · 0 · 3

So if you just use ActivityStreams' default stuff, it's easier, because you have just a smaller set of vocab to deal with. Suddenly you want or encounter extensions and oh shit, you hit the -LD side of JSON-LD, and that stuff is there for a reason

One thing we need to do is better document how to fold open world systems into closed world systems (eg people using highly structured DBs). Totally doable, but underdocumented.

The main thing you can and should do: compact incoming json-ld to your local world knowledge with your local json-ld context. (This is a one-line operation with any json-ld library.) Then you can treat it as "just json" and all the fields will be things you know. Store the fields you don't know about somewhere so you can get to them if you need them but they can be off to the side a bit.

@cwebber yeah that is exactly what I will be doing (when I will get to the point of doing the client part)

@cwebber fuuuck this reminds me i need to write a compactor

@cwebber it would be easier to do this if every extension had a link that actually resolves to anything. side-eyeing mastodon's custom stuff and ostatus here.

@KitRedgrave There's a whole discussion about whether terms should be resolvable and I agree it's nice when possible, but won't get into thatt famous battle :)

@cwebber well, if they're *not*, then you usually won't get all the information you need right away to see what an unfamiliar extension contains. that could be okayish but you'll be getting random bits of extension forever and have to figure out how to handle that.

all because somebody was too careless to throw a json-ld static file somewhere

@KitRedgrave generally I agree. I think the current state of URI terminology and contexts is fairly imperfect, and there's interest in some things that I think will improve stuff... but that's a conversation about making things better that's a bit too complicated to go into in this thread

@cwebber

But every computer program is, until we have human equivalent AI, a closed world. You can provide all the metadata you want about the open world, but if my program doesn't already have an idea about it, it can't do anything smarter with it than either ignore it or pretty print it.

I'm not trying to be argumentative as such; I *know* you've put a ton of thought into it. But I absolutely can't grasp where the LD community is coming from.

@gcupc @cwebber
As somebody who has written an open-world logic system, I value it because of the way dynamic loading and hot-swapping can change the results. This might not be a concern of semantic web technologies.

@gcupc *your* closed world may not have all the things in *my* closed world, and yet there are a lot of things we can communicate about.

Say you are a game developer and I am a vegan chef. You say "My boss was really bugging me that I need to improve my A* pathfinding algorithm." Well I don't know what a pathfinding algorithm is, but I can empathize about your boss situation. If I told you I made a good BBQ tempeh and you don't know what tempeh is, you at least might know BBQ.

@cwebber @gcupc this has been ANALOGIC PHILOSOPHY OF ONTOLOGIES, by CHRISTOPHER LEMMER-WEBBER

@er1n @cwebber @gcupc If you do mathematical work do you sign as Christopher Lemma-Webber 🤔

@elomatreb @er1n @gcupc Actually I don't put a hyphen in my last name, though @mlemweb does.

I haven't officially changed my name yet, but for the sake of paperwork minimization and local friend confusion maximization, I will be switching my middle name to my spouse's last name rather than hyphenating.

@cwebber @elomatreb @gcupc @mlemweb something something paperwork needs JSON-LD compaction

@cwebber Oh, sorry.

Yeah that sounds like a very pleasant bureaucracy trip

@gcupc I can at least operate on the things I know about, in my mind, and you can in yours.

The context bit comes in because our conversations are usually in contexts. Programs need that too, so we can know that "run" a program is not "run" a mile.

Even if the world is wide and open, within our closed minds, we can do a lot to understand and interact with each other. Indeed, we must, or we will only talk to ourselves.

@cwebber
I think that's, at best, a formula for making everyone a little bit unhappy.

And it's also a bad analogy. Humans are very good with ambiguity and working around missing knowledge. Computers are very bad at it.

@gcupc That's why the context maps to exact term URIs (Universal Resource Indicators). You and I at least can try to achieve rough consensus on what those specific terms mean.

@cwebber
"You and I" can, but our computer programs can't. All a JSON-LD context tells my program is that it's definitely entering territory it knows nothing about.

@gcupc And that's fine. Your program doesn't know about it, so now your program can ignore that thing for its own logic, but shove it somewhere so that when sharing it or etc, it can present it as part of the whole artifact in case another entity does.

Maybe you don't know what Tempeh is, but my friend Alice does, and now she can understand more when you relay it to her.

@cwebber
Right, so in practice, what this means is that basing ActivityPub on JSON-LD ensures that no two federated social networks will be fully compatible. And I know you consider this a good idea, but I can't understand why.

@cwebber
(That's leaving aside all of the critical interoperability parts of the spec that are left unspecified.)

@gcupc Do you consider it a good idea that at standards-writing time we assume that we can write all possible behavior for all time? I'm not so smug as to believe I can anticipate all needs of the fediverse.

We didn't define a document type for VirtualRealityRoom, for instance, but maybe in the future that's the most popular object type.

Should we say, "AP/AS2 didn't define it, thus it can't exist"?

@gcupc Closed world networked systems always get expanded into open world systems whether you like it or not. Do you plan for it or don't you?

@cwebber
Real standards get revised from time to time. And an implementation can specify which version of the standard it implements.

@gcupc Sorry but upgrading between standards revisions that don't build in support for extensibility barely happens. At my time in standards the most frequent regret I hear people say is "Well we thought people would be able to upgrade to API X.2, but it never happened... it turns out we were stuck on API X.1 forever."

@gcupc There's a network effect in non-extensible systems where if it's "all or nothing", movement is an insanely hard thing to do.

Look at IPv4 -> IPv6 as *still* an ongoing effort.

@cwebber
I am amazed to hear that no one uses HTTP 1.1 or HTTP/2. Or RFC 5322 for that matter.

@gcupc smtp is a great example of a) a standard that hasn't been updated but it would be nice if it could be and b) people awkwardly hacking in extensibility... x-foo-header

@cwebber @gcupc
We can have private logic about public items, too, right?

(I'm not totally clear on how inference works here, but in more conventional inference systems you have the concept of inference libraries with publicly exported predicate names whose actual implementation might change.)

Being able to merge inaccessible and contradictory logical rules is straightforward when names are canonical, so long as your operations also assume open world.

@cwebber @gcupc
(In other words, while we can expand possibilities, we can't operate based on the assumption that we have expanded all possibilities. Prolog's '/+' operator can't be treated as a 'not' operator, in other words, because 'impossible to prove' is concretely different from 'untrue' rather than more abstractly.)

@enkiv2 @gcupc Yes you can deal with those things, but I am explicitly not bringing logic systems into the discussion because most devs will not deal with them.

Very RDF'y semantic web'y people will... I always assume, however, that most developers are in a general webdev type mindset