FAQ

Frequently Asked Questions



General

While CASE and UCO haven’t yet put in a stance on this, it’s worth noting that the XML Schema source of basic RDF types does weigh in on this with the more stringent hexBinaryCanonical: Uppercase.

We can state as of CASE 0.2.0, there is no requirement either way.

JSON

There are several forms, influenced by ObjectProperty cardinality and namespace prefixes.

Each of these next few examples are legal standalone JSON-LD.  (That is, a graph engine can take them in if they were the sole contents of a JSON file.)

Example 1-1.  A reference to a single object in the full, no-niceties spelling in JSON-LD must be of the form:

{
  "@id": "http://example.org/kb/object1",
  "http://example.org/ontology/someProperty": {
    "@id": "http://example.org/kb/object2"
  }
}

This is an example of JSON-LD “Expanded document form.”

https://json-ld.org/spec/latest/json-ld/#expanded-document-form

Example 2-1.  A reference to multiple objects in unnecessarily-long, no-niceties, but still legal, JSON-LD can be of the form:

[
  {
    "@id": "http://example.org/kb/object1",
    "http://example.org/ontology/someProperty": {
      "@id": "http://example.org/kb/object2"
    }
  },
  {
    "@id": "http://example.org/kb/object1",
    "http://example.org/ontology/someProperty": {
      "@id": "http://example.org/kb/object3"
    }
  }
]

Example 2-2.  OR of this form:

{
  "@id": "http://example.org/kb/object1",
  "http://example.org/ontology/someProperty": [
    {"@id": "http://example.org/kb/object2"},
    {"@id": "http://example.org/kb/object3"}
  ]
}

Example 2-1 looks a bit ridiculous, but comes from RDF’s practice of letting you write all the facts in your knowledge base as full triples with a lot of redundant text.  E.g. examples 2-1 and 2-2 would both look like this in Turtle syntax:

<http://example.org/kb/object1>	<http://example.org/ontology/someProperty>	<http://example.org/kb/object2>	.
<http://example.org/kb/object1>	<http://example.org/ontology/someProperty>	<http://example.org/kb/object3>	.

This practice has significant benefits if you need to stash some triples about the same object in different files, e.g. by generating different Facets for the same object as outputs of independent processes.

Now, all of the above “No-nicety” examples are present to show the benefits of some shortening that is possible from the JSON-LD Context Dictionary.  Example 1-1 can be shortened to this form, which uses prefixes that you might be familiar with from XML.

Example 1-2:

{
  {
    "@context": {
      "kb": "http://example.org/kb/",
      "myont": "http://example.org/ontology/"
    }
  },
  {
    "@id": "kb:object1",
    "myont:someProperty": {
      "@id": "kb:object2"
    }
  }
}

It turns out there are is another nicety that can be applied, to specify that certain predicates are expected to always have objects as references, removing the need to nest a JSON dictionary.

Example 1-3:

{
  {
    "@context": {
      "kb": "http://example.org/kb/",
      "myont": "http://example.org/ontology/",
      "myont:someProperty": {
        "@type": "@id"
      }
    }
  },
  {
    "@id": "kb:object1",
    "myont:someProperty": "kb:object2"
  }
}

The short of the work ahead on context is, that whole @context JSON dictionary can be a JSON-LD file, specified by URL, that provides all of the JSON-not-LD syntactic simplifications the CASE and UCO communities think appropriate and helpful.  That file can be mostly (possibly entirely) mechanically derived from the CASE and UCO ontologies.  AND it can handle the cardinality matter, so something that could be a JSON array will always be a JSON array.