Create an interim blank node in JSON-LD - json

This JSON-LD document:
{
"#context": {
"#base": "local://",
"#vocab": "local://",
"class": {
"#type": "#id"
}
},
"#id": "boo",
"class": "Badam"
}
…results in the following triples according to JSON-LD Playground:
<local://boo> <local://class> <local://Badam> .
I would like to achieve something different. In particular, I would like to insert a new blank node and a property:
<local://boo> <local://class> _:b0 .
_:b0 <local://has-class> <local://Badam> .
Is this at all possible by the means of the #context? I haven't found anything suitable in JSON-LD specification. The nearest thing that I have found is "#container": "#list" because it does create an interim blank node, but obviously one cannot override the rdf:first property it uses replacing it by something else.

Related

Making Valid JSON-LD Schema & Object Instance

I'm trying to create a graph database for describing power systems and this is my first time using JSON-LD.
Steps so far:
Created a schema according to the following guide
Saved the schema to this url
Attempted to use JSON-LD playground to create and validate and instance of a power-station object described in the schema
The issue I'm facing is that my schema seems to be accepted (changing it creates an error) but no output is shown and no explanation is provided. Any help to work out what I'm missing would be much appreciated.
Schema
{
"$id": "https://osuked.github.io/Power-Station-Dictionary/power-station",
"type": "object",
"properties": {
"capacity": { "type": "float" },
"fuel-type": { "type": "string" }
},
"required": ["capacity", "fuel-type"]
}
Example object instance
{
"#context": "https://osuked.github.io/Power-Station-Dictionary/power-station.json",
"#id": "http://osuked.github.io/Drax",
"capacity": 12,
"fuel-type": "wind"
}
Check the definition of the context (https://json-ld.org/spec/latest/json-ld/#the-context). It must specify how your properties (capacity and fuel-type) map to RDF properties. You can either provide the definitions inline or point to a URL that contains this mapping (e.g. https://schema.org/docs/jsonldcontext.jsonld).
In your example, you provide the URL https://osuked.github.io/Power-Station-Dictionary/power-station.json. It contains a JSON document but does not contain the JSON-LD context, because JSON Schema != JSON LD (you might find this article helpful to understand the difference: https://dashjoin.medium.com/json-schema-schema-org-json-ld-whats-the-difference-e30d7315686a).
Therefore, the JSON LD playground does not show an error (no property definitions found) but also shows no parsed triples.
To fix this, you can try using "#context": "http://schema.org/", you can define a namespace prefix p,
{
"#context": {
"p": "https://osuked.github.io/Power-Station-Dictionary/power-station/"
},
"#id": "http://osuked.github.io/Drax",
"p:capacity": 12,
"p:fuel-type": "wind"
}
or define the properties individually:
{
"#context": {
"capacity": "https://osuked.github.io/Power-Station-Dictionary/power-station/capacity",
"fuel-type": "https://osuked.github.io/Power-Station-Dictionary/power-station/fuel-type"
},
"#id": "http://osuked.github.io/Drax",
"capacity": 12,
"fuel-type": "wind"
}

Proper validation of a referenced file when editing OpenAPI json in IntelliJ

I'm editing an OpenAPI JSON spec in IntelliJ. The automatic validation and code completion work very nicely.
The OpenAPI version used is 3.0.3, which IntelliJ detects correctly. It seems that it uses "openapi30.json" internally for validation, and all is good.
However, the file is getting very large and it's time to move some commonly-used models out of it using $ref.
This is where things break. The main spec looks like this (snippet):
{
"openapi": "3.0.3",
"info": {
"title": "Cars REST API",
"description": "Calls, Responses and DTOs for REST",
"version": "1.0.0"
},
"components": {
"schemas": {
"car": {
"$ref": "car.json"
},
"car-group": {
"$ref": "car-group.json"
}
And when editing it, IntelliJ recognizes it as "openapi30".
However, the referenced documents are not recognized. For example, the car.json file looks like this:
{
"car": {
"required": [
"id",
"name"
],
"properties": {
"id": {
"type": "integer",
"format": "int64"
},
"name": {
"type": "string"
},
"tag": {
"type": "string"
}
}
}
}
And it's recognized simply as a JSON document, not an OpenAPI one, so there is no proper validation and no code completion, etc.
How does one tell IntelliJ that the file is part of an OpenAPI specification, to be validated as such? One should think this could be inferred from begin $ref'ed from the main spec, but this doesn't work.
Trying to add a $schema value in the referenced file had no effect (and probably isn't in line with the OpenAPI spec anyway).
Manually selecting the OpenAPI 3.0 file type for car.json is not helpful, because then validation (rightly) fails - as it doesn't have the top-level structure required (info, openapi, paths).
Perhaps some specific JSON schema mapping needs to be added in IntelliJ preferences? If that's the case, it would be actually a sub-schema or some tag in the main OpenAPI spec, how can that be done?
IntelliJ version is: IntelliJ IDEA 2021.3.2 (Ultimate Edition)
Any help would be greatly appreciated.
Ron!
Such functionality is not yet supported. Please vote for https://youtrack.jetbrains.com/issue/IDEA-284305

What does mean #id and #type in json-ld context?

What does mean this statement in json-ld context?
{
"#context": {
"#version": 1.1,
"id": "#id",
"type": "#type"
}
}
and
{
"#context": {
"id": {"#type": "#id", "#id": "#id"},
"type": {"#type": "#id", "#id": "#type"}
}
}
I do not figure out that expression means what.
Json-Ld is designed to be interoperable with rdf. Therefore it introduces certain keywords marked with #. This keywords are needed to create rdf-statements from the json document.
A good starting point to get familar with the underlying concepts is to play around with the Json-Ld Playground. You will find some examples there. You can use the examples to create conversions from one format into another.
Getting rid of the '#'-character
Sometimes the '#'-character can become unhandy, e.g. when working with Javascript. In such situations it is possible to define an alias for an '#'-keyword. Like shown in your context:
{
"#context": {
"id": "#id",
"type": "#type"
}
}
By defining aliases for '#'-keywords the actual json document is easier to consume by non-rdf applications while it is still possible to process the data as rdf.

What is the correct way to nest Schema.org Property Types inside an Object Type in JSON-LD

Question:
How to nest a Schema.org property types inside an Object Type in a JSON-LD code?
Context:
I have a website with pages about the biography of persons. I have a validated JSON-LD code for the Schema.org Person Object Type.
I want to expand the code to include the persons that came before and after a person in a certain role. For example, if the page is about a mayor of a city, I want to add the previous and following mayors.
The closest properties I could find are follows for the previous mayor (link) and followee (link) for the following mayor.
The Problem:
The property follows was validated with no problems, but followee gave an error if placed directly under the Person type as it requires a FollowAction type.
The property #followee is not recognized by Google for an object of type Person.
Workaround Tried:
I tried to nest the code, but I could not do this successfully.
For example:
<script type="application/ld+json">
{
"#context": "http://schema.org/",
"#type": "Person",
"name": "john Citizen",
{
"#context": "http://schema.org/",
"#type": "FollowAction",
"followee": {
"#type": "Person",
"name": "Steve"
}
}
}
</script>
I tired several other variations, but all led to errors. Are there any feasible correction to the code, or alternative ways to achieve the goal?
As I mentioned in the comment, I don't think follows or FollowAction are appropriate for your use.
For academic purposes, there is a way to mark up FollowAction inside a person. As FollowAction can reference a Person via it's agent, but not the other way around, you can use the reverse property to indicate a kind of backward reference:
<script type="application/ld+json">
{
"#context": "http://schema.org/",
"#type": "Person",
"name": "john Citizen",
"#reverse": {
"agent":
{
"#type": "FollowAction",
"followee": {
"#type": "Person",
"name": "Steve"
}
}
}
}
</script>

JSON schema reference another element in the document

Is there a way to express reference to another element in the same JSON document using JSON schema? The title might be a bit confusing, but i'm not looking for the "$ref" attribute, which references another type, but I'm curious, if there is a way, to reference another element in the document using a specified field. I know this is possible to enforce using xsd for xml documents, not sure about JSON.
I want to do something like this:
{
"people": [
{ "id": "1", "name": "A" },
{ "id": "2", "name": "B" },
{ "id": "3", "name": "C" }
],
"chosenOne": "1" // I want the schema to enforce a person ID here
}
I have been looking at the schema definition of v4: http://json-schema.org/draft-04/schema but didn't find anything, that looks like what I'm trying to do. Did I just miss it?
What you want is that you describe a reference ($ref) in the object your schema is describing.
kind of like this
{
"people": []
"chosenOne": { $ref: "#1"}
}
(or maybe a pointer if you want the value of the Id (https://json-spec.readthedocs.io/pointer.html)
I know of no direct way to do this but you might be able to use the pattern or oneof properties to force it being the right value. Kind of like this
"properties": {
"chosenOne"
"type": "string",
"oneOf": ["1","2","3"]
]
},
}
Similarly you could force the value of the property to be a reference pattern. That said since there is no reference value type (http://www.tutorialspoint.com/json/json_data_types.htm) only number or string you can't guarantee the meaning of the value. You can just guarantee that if follows some kind of reference pattern.
If you need more than what json schema's can give you you might want to look in odata for example. OData has some extra things so you can describe an entitySet and then define a navigation property to that set.
It does however force you to follow the odata structure so you aren't as free as you would be with a regular json schema.