Import of JSON-LD files raises concerns

Virtuoso Universal Server RDF Data Management
1

Hello, all

recently unexpected results of JSONLD import were found in the following example:

  1. A JSONLD file below was successfully loaded to the named graph.
{
	  "@context": {
  },
  "@graph": [
{
    "@context": "dtmi:dtdl:context;2",
    "@id": "dtmi:digitaltwins:isa95:MaterialClass;1",
    "@type": "Interface",
    "displayName": "Material class",
    "description": "A representation of groupings of material definitions for a definite purpose such as manufacturing operations definition, scheduling, capability, and performance shall be presented as a material class. A material definition shall belong to zero or more material classes.",
    "comment": "According to ANSI/ISA-95.00.02-2018 Enterprise-Control System Integration − Part 2: Objects and Attributes for - Approved 24 May 2018",
    "extends": [
        "dtmi:digitaltwins:isa95:ResourceClass;1",
        "dtmi:digitaltwins:isa95:TestableObject;1"
    ],
    "contents": [
               {
            "@type": "Property",
            "name": "hierarchyScope",
            "displayName": "Hierarchy scope",
            "description": "Identifies where the exchanged information fits within the role based equipment hierarchy. Optionally, hierarchy scope defines the scope of the equipment class, such as the site or area where it is defined.",
            "schema": "string"
        }    ]
  }
  ]}

  1. In the process of SPARQL querying it was discovered that for objects of the “contents” predicate rdf:type statements were not created (for example, corresponding to “@type”: “Property”).

  2. If that named graph is exported to WebDAV, we can see that indeed information about rdf type is missing for the nodeID=“b63854”.

<?xml version="1.0" encoding="utf-8" ?>
<rdf:RDF
	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" >
  <rdf:Description rdf:about="dtmi:digitaltwins:isa95:MaterialClass;1">
    <rdf:type rdf:resource="urn:/Interface" />
    <comment>According to ANSI/ISA-95.00.02-2018 Enterprise-Control System Integration − Part 2: Objects and Attributes for - Approved 24 May 2018</comment>
    <contents rdf:nodeID="b63854" />
    <description>A representation of groupings of material definitions for a definite purpose such as manufacturing operations definition, scheduling, capability, and performance shall be presented as a material class. A material definition shall belong to zero or more material classes.</description>
    <displayName>Material class</displayName>
    <extends>dtmi:digitaltwins:isa95:ResourceClass;1</extends>
    <extends>dtmi:digitaltwins:isa95:TestableObject;1</extends>
  </rdf:Description>
  <rdf:Description rdf:nodeID="b63854">
    <description>Identifies where the exchanged information fits within the role based equipment hierarchy. Optionally, hierarchy scope defines the scope of the equipment class, such as the site or area where it is defined.</description>
    <displayName>Hierarchy scope</displayName>
    <name rdf:datatype="Property">hierarchyScope</name>
    <schema>string</schema>
  </rdf:Description>
</rdf:RDF>

It may be interesting to note, that for top-level classes statements with rdf:type were created as expected.

Is it expected behavior or a bug in import algorithms ?

2

@Eduard_BABKIN

It is rather suppressed error due to relaxed way JSON-LD import works, the context URI ‘dtmi:dtdl:context;2’ can not be resolved.

3

Yes, this is an issue that differentiates JSON-LD processing rules from other serialization formats i.e., @context URIs MUST resolve.

4

ok, that is clear. Could you, please, suggest minimal modifications of the JSON-LD file to allow using of @type inside nested structures ?

5

@Eduard_BABKIN

The way JSON-LD loader can handle unresolvable by http/s ways context is as follows:

curl  -sL "https://raw.githubusercontent.com/Azure/opendigitaltwins-dtdl/refs/heads/master/DTDL/v2/context/DTDL.v2.context.json" \
 | awk 'NR==1{sub(/^\xef\xbb\xbf/, "")} BEGIN { printf "{\"@context\": " } { print $0 } END { print "}"}' \
   > DTDL.v2.context.jsonld

Note: the DTDL.v2.context.json is NOT a context document but context content, thus need to wrap in { "@context": ... }

  • check the DTDL.v2.context.jsonld with jq or some other json tool if it is consistent JSON syntax

e.g.

 $ cat DTDL.v2.context.jsonld | jq

  • place the DTDL.v2.context.jsonld is place where can be accessed from Virtuoso server instance e.g. /tmp, check DirsAllowed config file and see is /tmp is enabled or place where the DTDL.v2.context.jsonld is created

  • cache the context

insert into SYS_CACHED_RESOURCES (CRES_URI, CRES_CONTENT) 
 values ('x-virt-cache-dtmi:dtdl:context;2', file_to_string('/tmp/DTDL.v2.context.jsonld'));

Note the ‘x-virt-cache-’ , this will instruct external resolver to look at cache. Therefore in your JSONLD you will need to change context from

      "@context": "dtmi:dtdl:context;2",

to

      "@context": "x-virt-cache-dtmi:dtdl:context;2",

Then load the JSON file, the types etc. should be resolved.

HTH