Ed SummersFeb 10, 2024

JSON-LD can be nice to work with as a JSON object, for example:

https://kolektiva.social/@anarchivist/111905336837934109.json

But it can also be very difficult to work with, for example:

https://id.loc.gov/authorities/subjects/sh85079255.jsonld

Since you don't really know what you're going to get you need to use heavy RDF processing tools just to work with some JSON data. I think that's why people don't like JSON-LD.

Show threadPatrick HochstenbachFeb 10, 2024
@edsu This just depends on the tooks loc.gov used to create the JSON-LD, right. It just could be a JSON file, pretty readable, with a context inline or known to exists. I'm not a big fan of JSON-LD but this is not the reason. It is a compromise solution. As ugly and use-full as XML.
Show threadEd SummersFeb 12, 2024

@hochstenbach here's what I ended up using:

https://gist.github.com/edsu/7d2d8fb2049075e76bfdf106b8805220

I kind of wanted to get some JSON-LD that only included the SKOS vocab but I wasn't quite sure how to do that with the frame...

Get some usable JSON for a given LC name or subject authority string: e.g. `./lcauthority.py "Southampton (England)"`

Get some usable JSON for a given LC name or subject authority string: e.g. `./lcauthority.py "Southampton (England)"` - lcauthority.py

Gist
Show threadPatrick Hochstenbach
@edsu I don't think with a frame one can filter on a whole vocabulary. But one can state : "I only want to see these and these JSON properties and skip the rest". The JSON could be a bit easier also with `"mads:elementList": { "@container": "@list" }` in the frame. If LOC doesn't want to do the frameing at their side (for them it would be much easier and less URL parsing), your code snippet provides a lot of inspiration for others how process this data easier.
Feb 12, 2024 at 4:42pmWeb
Show threadEd SummersFeb 12, 2024

@hochstenbach ok, I'm glad I didn't miss something obvious! I might package this up as a little library/cli just as an example of how framing can make the data easier to work with.

I also noticed that sometimes strings are expressed as language-literals and other times they're not, which complicates using the data a bit. I suppose using an rdf library would make that go away. I opened an issue to make sure I wasn't missing a way of making that easier with a frame:

https://github.com/digitalbazaar/pyld/issues/192

Language tagged strings · Issue #192 · digitalbazaar/pyld

I think it may be out of scope for Framing and pyld, but I was wondering if there is any way to ensure that string literals either appear as language tagged strings or without them? For example is ...

GitHub
Show threadPatrick HochstenbachFeb 12, 2024
@edsu I'm afraid this default language needs to be solved at rdf level (data cleaning, or the source providing an easier mapping) and not json-ld framing. See also : https://github.com/w3c/json-ld-framing/issues/156
Framing to a default language for the entire doc · Issue #156 · w3c/json-ld-framing

I'd hoped I could use Framing to take an incoming multilingual JSON-LD document down to a single language without having to set @language with every @value as seen in Example 13. Here's what I trie...

GitHub
Show threadEd SummersFeb 12, 2024
@hochstenbach ah, thanks for letting me know I wasn't missing something obvious.
Show threadRob SandersonFeb 15, 2024

@edsu @hochstenbach Garbage data from LC at fault here, not JSON-LD or PyLD. Not surprisingly.

IIIF has a good pattern for language maps: https://iiif.io/api/presentation/3.0/#language-of-property-values that makes usable JSON... assuming that the incoming data is also reasonable

Presentation API 3.0

IIIF is a set of open standards for delivering high-quality digital objects online at scale. It’s also the international community that makes it all work.

Show threadEd SummersFeb 15, 2024

@azaroth42 @hochstenbach lol -- that's kind of the problem. Isn't it valid JSON-LD?

I definitely didn't mean to blame PyLD. I only wanted to say that when people are using JSON on the web they shouldn't be required to pay the RDF tax (using an RDF processing library). It should be usable as JSON, like what you have done in the IIIF community.

Show threadRob SandersonFeb 16, 2024

@edsu @hochstenbach

It is valid JSON-LD, much like SOAP and RDF-XML are valid but terrible XML. LC needs to understand that the audience for data is data/software engineers, and engage with our community to produce content that is both useful and usable. Unfortunately, as you doubtless experienced in your time there, it falls on deaf ears :(

Show threadEd SummersFeb 16, 2024
@azaroth42 @hochstenbach I wouldn't say people were uninterested in improving things. I remember there were significant barriers to getting things done when they spanned different parts of the organization. I don't think people willfully make things hard to use at any rate. But, that was a long time ago in a galaxy far far away. Ok maybe not that far, just 7 miles ;-)