CBOR is a compact binary data serialization and messaging format. The @w3c "CBOR-LD 1.0" specification defines a compact binary format for #LinkedData, built on CBOR and compatible with #JSON-LD, designed for bandwidth-constrained environments and efficient storage #FPWD #timetogiveinput
➡️ https://www.w3.org/TR/cbor-ld-10/
It helps achieve semantic compression and smaller payloads, often delivering 60% or greater savings compared to generic compression.
Feedback welcome! https://github.com/w3c/cbor-ld/issues/
CBOR is a compact binary data serialization and messaging format. This specification defines CBOR-LD 1.0, a CBOR-based format to serialize Linked Data. The encoding is designed to leverage the existing JSON-LD ecosystem, which is deployed on hundreds of millions of systems today, to provide a compact serialization format for those seeking efficient encoding schemes for Linked Data. By utilizing semantic compression schemes, compression ratios in excess of 60% better than generalized compression schemes are possible. This format is primarily intended to be a way to use Linked Data in storage and bandwidth constrained programming environments, to build interoperable semantic wire-level protocols, and to efficiently store Linked Data in CBOR-based storage engines.
The #osflimburg workshop "Interoperability and Linked Data for Interdisciplinary Research: National Initiatives and Practical Perspectives" takes place on the Maastricht day https://www.openscience-maastricht.nl/12-june-2026/ #openscience #linkedData
"The session will briefly outline how interoperability and Linked Data function as enabling mechanisms for interdisciplinary research, supporting data integration, reuse, and semantic alignment across disciplines."
Linked data viewer / resolver LDView has improved display of blank nodes / skolems and inverse relations.
Fwd: "18th Semantic Web in Libraries Conference" https://forum.swib.org/t/swib26-welcome/1661
"The topics of talks and workshops at SWIB revolve around opening data, linking data and creating tools and software for LOD production scenarios."
The "which BIT" and the - as I call it - #LinkedData conundrum, I addressed recently in a #SocialHub topic on the #JSONLD vs plain #JSON nature of #ActivityPub. Inspired to write a long and personal #SocialExperience tale on my travels in wild #fedi lands. See..
https://social.coop/@smallcircles/116368803389082089
The #EU @ngi #grant programs and the hard work of @nlnet to distribute @EUCommission Horizon Europe #funding has done wonders to take #fediverse where it stands today. In my article I list all the many #FOSS projects that received stimulus and support during the years.
However something fundamental has been lacking in the mandate on who is eligible. Coding is Social. The support does not cover the rich tapestry of #expertise that end-to-end #solutions need during their lifecycle. Does not include fostering cohesive #technology ecosystems, healthy #OpenStandards evolution.
Effectively this creates a 'handover point' of software code from poor FOSS to others who earn a living with it.
As precursor to my blog post announcement later today, here's my #SocialHub response to the topic on how to treat the #LinkedData based #ActivityPub open standard where messages can be expressed both as plain #JSON as well as in #JSONLD, leading to the most costly misconception that has dragged the #fediverse sideways from its original promise and power..
https://socialhub.activitypub.rocks/t/practices-around-json-formatting-of-json-ld-messages/8628/24
Fediverse-we-have is at a major inflection point And so I did, and seeing all the discussion here for which I thank you all, I decided to put in way more effort than originally intended, and delving into much deeper subject matter. The article quotes @SorteKanin and mentions others in this thread, especially @silverpill as the pillar who upholds the FEP process today. I read the discussion with interest, but skipping the implementation details, to take a broader perspective. All of you are rig...
> As an aside, I'm quite liking the ActivityPub APIs so far, although ld-json does leave me feeling like there's a fair jump from "script that works" to "actually does everything the spec would theoretically allow".
There's the "linked data conundrum" as I call it, which recently reared its head again, triggered by a #SocialHub post I created the other day:
https://socialhub.activitypub.rocks/t/practices-around-json-formatting-of-json-ld-messages/8628
The #LinkedData conundrum is the eternal friction between the plain #JSON and the #JSONLD view of the #ActivityPub social web. And it has never really be solved. I consider it one of the misconception that led to endless discussion, confusion, and waste of time. For the ActivityPub API which hold the promise to correct course towards a more standards-compliant #fediverse, I created an issue on the subject..
https://github.com/swicg/activitypub-api/issues/63
Followed by another on protocol design..
ActivityPub is primarily a Linked Data standard. It offers an option for developers to treat it as plain JSON for convenient processing by web technologies. I wonder about the common practice to @context mapping of namespaces to avoid use of namespace prefix in the body of the JSON message. Aren’t we making things too convenient? The problem is that ActivityStreams is a much overused and overloaded vocabulary already, where developers try (and are even encouraged) to map their own application ...
Pieter Heyvaert
дблп - ☮ Stop the war!
W3C Developers
Open Science Festival Limburg
d'aïeux et d'ailleurs
René Voorburg
Egon Willigh☮gen 🟥
🫧 socialcoding..