Mastodawn

🫧 socialcoding..Mar 4

@gugurumbe

Yes, thank you. It is a bit of everything. Where I worked in Print production at the time we used all the XML standards to max extent and got great benefit from doing so. It all crumbled down very quickly with the take-off of Web where #JSON mapped way better to JS than #XML did, esp. when also honoring the intricate web of (de-facto) standards that had emerged, and how the XML ecosystem got captured by corporations peddling expensive products, such Enterprise service buses and the like.

It would have been great if #XHTML had stuck around. In hindsight the shift to HTML5 may be seen as a move by the WHATWG to establish their dominance over the #browser market.

As for #JSONLD it must see to rewin hearts and minds, must inspire and convince people to take the bet of adopting it.

@strypey @FinchHaven @naturzukunft2026

🫧 socialcoding..Mar 3

For the sake of further clarity I should point to your starting post and this text:

> we need domain-specific applications that leverage ActivityPub’s full semantic potential

And remark that in my opinion and by observation, tapping the sign "Reminder: #ActivityPub is #JSONLD, folks!" isn't enough. Much more is needed than pointing to the #OpenStandards to win back developers minds to adopt #LinkedData. There is a high reluctance and resistance to adoption that must be overcome.

Referring again to that adoption chart I drafted the other day - which is about #SolidProject, but this is where LD is strong(est?) today - "build open standards, and they will come" isn't going so well. I hope that changes, as I have always been a fan of the *notion* of the semantic web. Yet in role of a technology decision maker, not ready to bet on it for a social networking environment.

Vivien (dentelle & numérique)Feb 23

Reading the json-ld best practices does not convince me that opaque external contexts should be allowed to change the interpretation of the data. #jsonld

#ActivityPub #ActivityStreams #RDF #JSONLD

I suspect that there is an error in the Turtle specification, in the section shown in the screen-shot.

(It relates to JSON-LD, which ActivityPub / ActivityStreams is built on.)

I suspect that "PN_CHARS_BASE" is an error.

Because other parts of other specifications seem to not make sense if it is.

I suspect that maybe it should have been "PN_PREFIX" instead.

#ActivityPub #ActivityStreams #JSONLD #RFC7159 #RFC8259

There is a larger discussion about fixed-point numbers versus floating-point numbers.

And that, ALL programming-languages should have fixed-point numbers built into them.

And that, programmers should be warned against using floating-point numbers in all but a set of very specialized situations — where inexact math is OK.

For most programmers in most situations inexact math is NOT OK. And, they should NOT use floating-point numbers.

RE: https://mastodon.social/@reiver/115956356584464586

This is likely (directly or indirectly) the fault of a single paragraph in IETF RFC-7159 / RFC-8259 (shown in the attached screen-shot).

(And note that, there is a difference between JSON and IETF JSON. JSON did not have this. IETF JSON does.)

That paragraph (in the IETF RFC) was NOT a requirement. But, others made it a requirement — including JSON-LD.

#ActivityPub #ActivityStreams #JSONLD #RFC7159 #RFC8259