@disarray take a look y'all: PE-19847-V2.1.pdf AVI-1276b.avi
trwnh@mastodon.social
Posts
-
@disarray hello i would like to formally file for an exemption -
@disarray hello i would like to formally file for an exemption@disarray hello i would like to formally file for an exemption
-
@erincandescent xri let you delegate to another authority at any point in the middle of the identifier@erincandescent one of the things i'm leaving out here is the distinction between base-relative ids and vocab-relative ids
you could simplify a lot of this with jsonld as well, for example eliding out the set/list stuff. but the more "context" you add/require, the harder it is to undo that. i'm pretty sure that when people say they hate jsonld what they mean is that they hate that this inherent complexity is hidden from you by the context mapping
there's probably a midway point or compromise
-
@erincandescent xri let you delegate to another authority at any point in the middle of the identifier@erincandescent xri let you delegate to another authority at any point in the middle of the identifier
i think even with redesigning from principles i would probably start off without any mechanism for property paths, but this could be added later as an extension by creating a "path entity" which is a json object that has a property pointing to a list of path components. something like
{"to": {
"set": [
{"id": "trwnh"},
{"path": {"list": ["trwnh", "as:followers"]}}
]}}but idk if this helps
-
thinkin bout the jsonld hate again and i think the real problem is not the ld, it's that it allows you to keep doing bad json.@erincandescent also you can use property paths like <trwnh>/as:followers in vaguely sparql (or what you're describing would be more like shacl paths). i think the equivalent json would be something like jsonpath or rfc6901 json pointers but that would be kind of hard to express and it also complicates things a lot to say that instead of referring to things directly you might need to follow a path which could involve resolving multiple documents
actually this is kinda what xri did, isn't it?
-
thinkin bout the jsonld hate again and i think the real problem is not the ld, it's that it allows you to keep doing bad json.@erincandescent i made a shitpost that as2 should have used hal+json instead https://mastodon.social/@trwnh/113266744971942546
honestly we don't need to use hal+json specifically but we should definitely take inspiration from it in what we want our compacted jsonld to look like.
-
thinkin bout the jsonld hate again and i think the real problem is not the ld, it's that it allows you to keep doing bad json.so instead of
{"items": "something"}
you would need to be explicit and say
{"items": {
"list": [{"id": "something"}]
}}this differs very slightly from json-ld expanded form in that a) you can use simple term definitions in an optional context mapping to provide simple namespacing lookup, and b) your entrypoint is not always an implicit graph, it's allowed to be an object, and if you want to refer to a graph then you can use a graph object instead
-
thinkin bout the jsonld hate again and i think the real problem is not the ld, it's that it allows you to keep doing bad json.@erincandescent all json really needs is a way to signal that something is an object and not a literal. we have a way of doing that: make the object into a json object! this means actor:someone is not enough anymore, you need actor:{id:someone}
similarly the way you signal that something can have multiple values is not to just say "everything can have multiple values", it's to make it an array. but then you need to specify whether the array is ordered or unordered. which you can do with objects
-
thinkin bout the jsonld hate again and i think the real problem is not the ld, it's that it allows you to keep doing bad json.@erincandescent idk about this one, i think you should be required to know the iri of my followers collection before being able to address it. but i'm split on it because i think that having the followers collection's iri being known is a prerequisite to knowing that the actor handles AP Follow activities. the "follow protocol" doesn't make sense without it. funnily enough as:followers is optional not required. so rather than duck-typing off presence of as:followers we need an explicit flag
-
thinkin bout the jsonld hate again and i think the real problem is not the ld, it's that it allows you to keep doing bad json.@erincandescent idk if Turtle is better than JSON-LD even though i generally prefer working with Turtle. the problem is that AS2 is just weird in so many ways due to that underspecification and also what i refer to as the connections between building blocks -- things like the Invite activity being a special case where the as:object is not the actual object of that activity, you're not inviting a party, you're inviting *someone* to that party. that's just bad semantics at the modeling level.
-
@erincandescent technically you can do that with Turtle too, if you want or need a more complete or authoritative graph@erincandescent technically you can do that with Turtle too, if you want or need a more complete or authoritative graph
blank nodes don't really suck IMO they are a convenient way to provide indirection when not everything has an explicit name or identifier. it makes more sense to me to call them "anonymous nodes" that get assigned a pointer or reference automatically
-
thinkin bout the jsonld hate again and i think the real problem is not the ld, it's that it allows you to keep doing bad json.a little more explicitness upfront would have saved everyone a lot of trouble, and it's sad that as2 got finalized in the state that it did. the vocabulary is generally decent in the concepts and building blocks it identifies, but they just don't connect in the way that you'd expect or even understand.
-
thinkin bout the jsonld hate again and i think the real problem is not the ld, it's that it allows you to keep doing bad json.if you were doing this "right", then you would end up needing a second term `closedBy` to represent cases where as:closed refers to an object, instead of `closed` which has a literal value.
a similar thing happens with as:items. we actually need two terms: `items` which refers to the default container of an unordered set, and `orderedItems` which tacks on container:list to the context mapping's term definition.
this is not the fault of jsonld, it's the fault of overly broad schemas/"bad json".
-
thinkin bout the jsonld hate again and i think the real problem is not the ld, it's that it allows you to keep doing bad json.the proper use of context mappings is to transform ambiguous json into unambiguous json(ld). not to force everyone to use ambiguous json in exactly the same way that you use it.
this is also made worse by the fact that the as2 vocab is sometimes defined in a way that is so "bad" that it is *impossible* to express using a single term! case in point: take as:closed. it can be both an object (Object or Link), or a literal (datetime or boolean). how do you model that cleanly?
-
thinkin bout the jsonld hate again and i think the real problem is not the ld, it's that it allows you to keep doing bad json.this is something that can't be fixed about as2 as a profile or media format unless you make a new context document and force people to be consistent with that new context mapping, which would have to limit itself to simple term definitions. (none of the fancy stuff.)
the thing is, humans can deal with ambiguity. machines can't. as2 is overly optimized for human readability, to the point that it creates a lot of ambiguity for machines.
-
thinkin bout the jsonld hate again and i think the real problem is not the ld, it's that it allows you to keep doing bad json.here's an example from an earlier post https://mastodon.social/@trwnh/113266766055627285
simply *dropping* type:id from the context mapping of every single term would have changed the compacted output to use a json hashmap every time you refer to an object, and each object can have a single key `id` in it at minimum.
i bet if this was the case, then the complaints about "jsonld" would *sharply* drop. it would just be a fancy namespace at that point, and people don't complain about aliasing/includes/imports as much.
-
thinkin bout the jsonld hate again and i think the real problem is not the ld, it's that it allows you to keep doing bad json.in a sense, the as2 requirement to be consistent with the *compacted* form means that you have to be as indirect as the context mapping tells you to be. if the w3.org/ns/activitystreams context did some wack shit then you would have to unwrap all the resulting wack behavior. and type:id is the biggest kludge ever because it makes it ambiguous whether anything is a literal value or an actual object.
-
thinkin bout the jsonld hate again and i think the real problem is not the ld, it's that it allows you to keep doing bad json.thinkin bout the jsonld hate again and i think the real problem is not the ld, it's that it allows you to keep doing bad json. the context mapping is a wonderful tool for indirection, which is good when you want to take ambiguous structure and make it unambiguous (through expansion), but if you're working at the plain-json level then you are at the mercy of whoever designed the json api/structure/schema in the first place. you have to deal with all the ambiguity inherent to the bad json.
-
sure, "worse is better", but also, worse is worse.might expand on this when i have the time, but the main thesis is that a) we keep dooming ourselves to "worse" futures than what could have been, b) we ought not to "settle" for the "worse" thing, c) things can be "worse" but they really don't have to be *that much* "worse"
conclusion: it may be a pattern, but consigning yourself to it as a mindset is a form of abdication
-
sure, "worse is better", but also, worse is worse.sure, "worse is better", but also, worse is worse.