References as JSON-LD

[namedgraph]

Consider adding a JSON-LD @context? That would make the specref JSON data immediately available to the RDF-based Semantic Web/Linked Data/Knowledge Graph ecosystem.

More information: https://www.w3.org/TR/json-ld11/#the-context https://json-ld.org/

[tobie]

I’m happy to take a pull request.

[marcoscaceres]

RDF-based Semantic Web/Linked Data/Knowledge Graph ecosystem.

Interesting. Which system could consume this data? We’ve generally held off adding this JSON-LD because we couldn’t find any real consumers.

[namedgraph]

Well for one search engines are indexing JSON-LD for SEO purposes: https://developers.google.com/search/docs/guides/intro-structured-data

As for the open-source community, specref would become a part of the LOD cloud: https://lod-cloud.net/

Most modern RDF libraries can consume JSON-LD. So for example, I could load specref data into a triplestore and run some SPARQL queries on it.

[namedgraph]

@tobie at a first glance, it would probably need some slight restructuring of the JSON data. I'm not an expert in JSON-LD specifically, more RDF in general, but I can try to get someone to look into this.

It's because in RDF the URI is the global identifier (built into the data model). So the @href value would be the ID of the spec, while the short name you're using as the key would become just one of its properties.

So for example the N3 entry would look something like this in JSON-LD, using schema.org as the vocabulary:

{
    "@context": "https://schema.org/docs/jsonldcontext.json",
    "@id": "https://www.w3.org/TeamSubmission/2008/SUBM-n3-20080114/",
    "name": "Notation3 (N3): A readable RDF syntax",      
    "alternateName": "N3",      
    "author": [
        { "name": "Tim Berners-Lee" },
        { "name": "Dan Connolly" }
    ],
    "date": "2008-01-14",
    "status": "W3C Team Submission",
    "publisher": { "name": "W3C" }
}

You can paste this into the JSON-LD Playground, click on the N-Quads tab and see the RDF triples that this JSON-LD parses to.

[marcoscaceres]

Well for one search engines are indexing JSON-LD for SEO purposes:

ReSpec includes JSON-LD descriptions of specs, but unfortunately we’ve seen little benefits. I was hoping better UI in search results for specs, but it seems support in search engines is limited at best.

As for the open-source community, specref would become a part of the LOD cloud:

Ok, but then what? How do regular users of specref benefit? How do spec writers benefit?

Most modern RDF libraries can consume JSON-LD. So for example, I could load specref data into a triplestore and run some SPARQL queries on it.

Could do the same with SQL and GraphQL, no? We do the lookups already with the JSON structure (e.g., query title, etc.). I guess my point is that it just feels like JSON-LD is a solution to a solved problem and little demonstrated value for end users (and a bunch of needless complexity).

[tobie]

Ok, so a solution that requires a profound schema change like you’re describing isn’t possible. It could be something additional, but we can’t have a modification like that to the main API.

[namedgraph]

@marcoscaceres I don't want to get into RDF vs. JSON here, but RDF was designed specifically for web-based data interchange, enabled by two main features:

• built-in global identifiers (URIs)
• zero-cost generic merge

JSON does not have either of those. I could have built my own DB similar to specref but with slightly different JSON structure, and if we decided to merge the efforts, we would need align the structures first. That is complexity, growing with the number of datasources.

With RDF, there is no need for alignment, because there is only one way to structure the data: triples. JSON-LD is just the surface syntax for them, among other formats. (OK there might be a need to align vocabularies, but that can be done with a single SPARQL command).

If I have RDF data referencing some of specification URIs, I could simply append specref JSON-LD to my DB and get a bunch of metadata for free, which I then can use to render in the UI, for example. Or, if someone would be running a specref SPARQL endpoint, I wouldn't even need to load the data -- I could access it on the fly using query federation.

[tobie]

Alright, I'm happy to consider a parallel API that would be JSON-LD and happy to take a pull request for it granted it doesn't create more work for me.

[tobie]

Feel free to reopen this issue or open a new one if/when you want to discuss the specifics of that additional API.