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.
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
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.
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
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.
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
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.
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
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?
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
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".
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
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.
-
erincandescent@akko.erincandescent.netreplied to trwnh@mastodon.social last edited by
@trwnh I think I generally agree with you; the vocabulary is underspecified in various ways, and it bends JSON & JSON-LD into various contortions in order to hammer them to fit.
I’m unsure how much of my feeling that AS1 was better is rooted in “some of the changes in AS2 add degrees of freedom that make effectively processing AS2 documents harder” and how much of it is rooted in “AS2 is straddling the RDF/JSON boundary in a way that is really uncomfortable and harming it as a specification”
Once again I can’t help but think “Turtle is a better serialization of AS2 than the actual JSON representation”…
-
erincandescent@akko.erincandescent.netreplied to erincandescent@akko.erincandescent.net last edited by
@trwnh One thing I will say against the RDF model is that sometimes you want what I’ll call “inherent/structural children” of an object (think here: most uses of AS2
Link
objects, which themselves don’t have an@id
) and bnodes kinda suck for this (but they’re OK), but the fact that you can just go and reference an external document is kind of maddening -
erincandescent@akko.erincandescent.netreplied to erincandescent@akko.erincandescent.net last edited by
@trwnh (similar thoughts come up w.r.t “structural addressing” too; your followers/following collections needn’t necessarily have explicit URLs, instead of addressing
https://mastodon.social/users/trwnh/followers
I should be able to address<https://mastodon.social/users/trwnh>'s followers
; instead ofhttps://mastodon.social/users/trwnh/statuses/113301607066213459/replies
I should be able to address<https://mastodon.social/users/trwnh/statuses/113301607066213459>'s replies
-
trwnh@mastodon.socialreplied to erincandescent@akko.erincandescent.net last edited by
@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.
-
trwnh@mastodon.socialreplied to erincandescent@akko.erincandescent.net last edited by
@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
-
erincandescent@akko.erincandescent.netreplied to trwnh@mastodon.social last edited by
@trwnh So IMO: Expanded JSON-LD is workable. Its very tedious. Nobody wants to work that way. But it’s workable
Compacted opens up so many opportunities for inconsistencies and pain. It’s pretending to be JSON but its not.
Turtle has the advantage that its not pretending that RDF is JSON. You don’t have
orderedItems
vsitems
nonsense. Its very visible whether something is an<url>
or"string"
.Trying to squish everything into JSON just sucks because JSON is inexpressive. Its why it has succeeded at becoming the universal language but also it sucks.
-
trwnh@mastodon.socialreplied to erincandescent@akko.erincandescent.net last edited by
@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
-
erincandescent@akko.erincandescent.netreplied to trwnh@mastodon.social last edited by
@trwnh That might be fine for addressing but I think its painful for receive processing; you need to index all of these special purpose URLs.
But if I were designing these URLs they would probably be relationship tuple paths
(<https://mastodon.social/users/trwnh> as:followers)
if that makes sense to you -
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
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
-
trwnh@mastodon.socialreplied to erincandescent@akko.erincandescent.net last edited by
@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.
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
@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?