JSON-LD context issues to generate SKG from graph

[rapw3k]

Hi,
we have been working to implement the SKG-IF in ROHub
The first demo implementation used a json template to generate the output in the form we expect.
However, instead of making a json(-ld) file “manually” we want now to generate it directly from our graph data (as RO are graphs as you know).

The problem is that our skg context is having some challenges.
Among others, it defines multiple aliases for the same property (for the same entity type).
This can be used to get the triples from a json-ld using this context, no problem,
But getting back from triples to the json-ld we want is not achievable directly.
Another similar problem is the class property defined as rdf:type as well, there is not way to get this directly from triples.

Of course both problems can be addressed by creating some "fake" triples so it will be possible to get

Other issues were about

• using @type = @vocab in some properties that are not having as value terms from the context necessarly
• missing @container = @set for various terms which are expected to be arrays in the final serialization

I have made the best possible transformation from rdf triples to get skg-if.
I created a frame, with various changes from the original context.
Note i dont define all the terms from skg context as i dont need them all for rohub.

You can find all the results in https://github.com/rohub/skg/tree/main/implementation

You will find input file with triples, the frame, a small script to generate the json-ld (framed) and the output i get, which is perfectly aligned with the skg-if. To get that, though, i had to add two "fake" triples and make the corredsponding changes in frame context, namely to get the product_type and the class ( i used fake properties rdf:subtype and rdf:type2)

[rduyme]

Thanks Raul,

Silvio @essepuntato

Is there a way to fix the SKG-IF JSON-LD context to avoid elements Raul had to reshape in the frame ?

ex:

... 
 "type": {
          "@id": "rdf:type1",
          "@context": {
             "class": "@id",
             "defined_in": { "@id": "skos:inScheme", "@type": "@vocab" },
             "labels": { "@id": "skos:prefLabel", "@container": "@language" }
          }
        },
...
 "product_type": {"@id": "rdf:subtype", "@type": "@vocab" }
...

see : https://github.com/rohub/skg/tree/main/implementation => https://github.com/rohub/skg/blob/main/implementation/skg-frame.jsonld

[menzowindhouwer]

Hi, we noticed similar issues:

if we have this TTL following the SKG-IF data model:

<file:///app/oai_www_mpi_nl_lat_1839_00_0000_0000_0000_30B0_2.rdf>
        rdf:type                fabio:Dataset , fabio:Work ;
        dc:abstract             "MPI Project Temporality " ;
        dc:title                "Barbsch L1" ;
        datacite:hasIdentifier  [ rdf:type                       datacite:Identifier ;
                                  datacite:usesIdentifierScheme  datacite:handle ;
                                  silvio:hasLiteralValue         "https://hdl.handle.net/1839/00-0000-0000-0000-30B0-2"
                                ] .

which we turn into JSON-LD:

{
    "@context": [
        "https://w3id.org/skg-if/context/1.1.0/skg-if.json",
        "https://w3id.org/skg-if/context/1.0.0/skg-if-api.json",
        {"@base": "https://w3id.org/skg-if/sandbox/my-skg-acronym/"}
    ],
    "@graph": [
        {
            "local_identifier": "oai_www_mpi_nl_lat_1839_00_0000_0000_0000_30B0_2",
            "entity_type": "product",
            "product_type": "research data",
            "titles": {
                "en": ["Barbsch L1"]
            },
            "abstracts": {
                "en": ["MPI Project Temporality"]
            },
            "identifiers": [
                {
                    "value": "https://hdl.handle.net/1839/00-0000-0000-0000-30B0-2",
                    "scheme": "handle"
                }
            ]
        }
    ]
}

and we turn this back to TTL using the playground:

<https://w3id.org/skg-if/sandbox/my-skg-acronym/oai_www_mpi_nl_lat_1839_00_0000_0000_0000_30B0_2> <http://purl.org/dc/terms/abstract> "MPI Project Temporality"@en .
<https://w3id.org/skg-if/sandbox/my-skg-acronym/oai_www_mpi_nl_lat_1839_00_0000_0000_0000_30B0_2> <http://purl.org/dc/terms/title> "Barbsch L1"@en .
<https://w3id.org/skg-if/sandbox/my-skg-acronym/oai_www_mpi_nl_lat_1839_00_0000_0000_0000_30B0_2> <http://purl.org/spar/datacite/hasIdentifier> _:b0 .
<https://w3id.org/skg-if/sandbox/my-skg-acronym/oai_www_mpi_nl_lat_1839_00_0000_0000_0000_30B0_2> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://purl.org/spar/fabio/Dataset> .
<https://w3id.org/skg-if/sandbox/my-skg-acronym/oai_www_mpi_nl_lat_1839_00_0000_0000_0000_30B0_2> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://purl.org/spar/fabio/Work> .
_:b0 <http://purl.org/spar/datacite/usesIdentifierScheme> <http://purl.org/spar/datacite/handle> .
_:b0 <http://www.essepuntato.it/2010/06/literalreification/hasLiteralValue> "https://hdl.handle.net/1839/00-0000-0000-0000-30B0-2" .

we lose rdf:type datacite:Identifier for the identifier blank node

[rduyme]

@essepuntato Hi Silvio, could we get your feedback on this issue ?

[essepuntato]

Hi @rapw3k, all,

Short answer: the JSON-LD format used by SKG-IF has been devised for simplifying the JSON-to-RDF conversion (i.e. in favour of Web developers with no Semantic Web expertise), not vice versa.

Long answer: Thanks for your comment and suggestions. We are aware that multiple keywords map to the same OWL entity. The point of the work done for SKG-IF was to provide a JSON format first, easy to understand for Web developers (who may not have experience with Semantic Web technologies), which also makes it possible to view (via a purely automated process) as an RDF graph for semantic interoperability. Thus, in devising the JSON keys, we have followed the implicit rule that they should be clear in the context in which they are used (i.e., the specific type of concept that allows them to be specified).

Thus, I agree that the JSON-LD format, as defined, does not allow an automatic RDF-to-JSON-LD conversion, mainly because it was designed (and developed) with the other way around in mind, i.e., the JSON-to-RDF conversion. In some cases, it was possible to keep, across the SKG-IF main entities, the same key to deliver that concept (e.g. identifiers for datacite:hasIdentifier, pointing to an individual of the class datacite:Identifier). On other occasions, that was not possible - e.g., the case of affiliations for agents who are people and contributions for research products. They both are modelled using the Publishing Roles Ontology (PRO, http://purl.org/spar/pro), but they reuse it with different configurations to deliver the correct semantics.

About the fact that we are missing type relations for certain objects (e.g. identifiers), that is on purpose, and it is related to what I explained above. In practice, in SKG-IF, only six entities are actually represented (research product, agent, venue, topic, grant, data source) and, as a consequence, have an explicit type specified. In the diagrams of the SKG-IF data model, the main entities are represented in yellow boxes. All the others, the blue boxes in the data model, are the intended types for all the other secondary entities involved, but they are not explicitly defined with a statement. The idea is that they are derivative entities, i.e., they exist because of the main ones, and, to simplify life for us developers, we avoided adding keys that aren't necessary. For instance, for a Web developer, it is normal that anything included in the key identifiers is an identifier, regardless of what the RDF says. And, in that particular case, it is even implicitly true since the property datacite:hasIdentifier has the class datacite:Identifier as the range.

The only exception to this rule is when there is the possibility of adding other (external) types to given resources – e.g. see the type field within the manifestations of the research object. This has been done on purpose in order to avoid to force a specific taxonomy of types for the manifestations.

Anyway, modifications that enable us to do in a better way some passages are more than welcome. For instance, it is totally clear the comments about @vocab and @set mentioned before, and I think we can include some of these within the current context without breaking the way it is functioning right now. Something that we should check carefully, anyway.

I hope this clarified all the choices in this context.

[rduyme]

Thanks Silvio @essepuntato.

• I understand there are just a few elements we can improve, but it will not be a perfect round trip JSON-to-RDF / RDF-to-JSON
• As you mentioned, do you have time to update the context where it is possible for @vocab and @set ?