Assuming we want to access employees through the organization they work for but actually store the relation only at the employee entities, we need the following information from the perspective of the Organization schema:
- the name of the reverse keyword in the Organization schema
- the name of the forward keyword in the Person schema
- the RDF mapping of both keywords (not strictly necessary depending on the backend)
A possible notation:
Organization.schema.json
{
"@context": {
"schema": "http://schema.org/",
"type": "@type",
"employees": {
"@reverse": "schema:works_for",
"@type": "@id"
},
"$schema": "http://w3id.org/oo-ld/v0.1/schema.json",
"$id": "Organization.schema.json",
"title": "Organization",
"type": "object",
"properties": {
"type": {
"type": "string",
"const": "schema:Organization"
}
},
"x-oold-reverse-properties": {
"employees": {
"type": "array",
"items": {
"type": "string",
"format": "iri",
"range": {
"allOf": {
"$ref": "Person.schema.json"
}
}
}
}
}
}
Person.schema.json
{
"@context": {
"schema": "http://schema.org/",
"works_for": "schema:worksFor",
"type": "@type"
},
"$id": "Person.schema.json",
"title": "Person",
"type": "object",
"properties": {
"type": {
"type": "string",
"const": "schema:Person",
}
"works_for": {
"type": "string",
"range": {
"allOf": {
"$ref": "Organization.schema.json"
}
},
"description": "IRI pointing to an instance of schema:Organization",
}
}
}
OO-LD aware tools may preprocess the schema in order to create the "virtual" property _employees to allow e.g. editing employees in the organization edit form or accessing the employee object from the organization object in python:
{
"properties": {
"type": {
"type": "string",
"const": "schema:Organization"
},
"_employees": {
"type": "array",
"items": {
"type": "string",
"format": "iri",
"range": {
"allOf": {
"$ref": "Person.schema.json"
}
}
}
}
}
}
Note: Forward and reverse property slots can be autogenerated from an owl:ObjectProperty
schema:works_for a owl:ObjectProperty;
rdfs:domain schema:Person;
rdfs:range schema:Organization;
owl:InverseOf schema:employee.
Assuming we want to access employees through the organization they work for but actually store the relation only at the employee entities, we need the following information from the perspective of the Organization schema:
A possible notation:
{ "@context": { "schema": "http://schema.org/", "type": "@type", "employees": { "@reverse": "schema:works_for", "@type": "@id" }, "$schema": "http://w3id.org/oo-ld/v0.1/schema.json", "$id": "Organization.schema.json", "title": "Organization", "type": "object", "properties": { "type": { "type": "string", "const": "schema:Organization" } }, "x-oold-reverse-properties": { "employees": { "type": "array", "items": { "type": "string", "format": "iri", "range": { "allOf": { "$ref": "Person.schema.json" } } } } } }{ "@context": { "schema": "http://schema.org/", "works_for": "schema:worksFor", "type": "@type" }, "$id": "Person.schema.json", "title": "Person", "type": "object", "properties": { "type": { "type": "string", "const": "schema:Person", } "works_for": { "type": "string", "range": { "allOf": { "$ref": "Organization.schema.json" } }, "description": "IRI pointing to an instance of schema:Organization", } } }OO-LD aware tools may preprocess the schema in order to create the "virtual" property
_employeesto allow e.g. editing employees in the organization edit form or accessing the employee object from the organization object in python:{ "properties": { "type": { "type": "string", "const": "schema:Organization" }, "_employees": { "type": "array", "items": { "type": "string", "format": "iri", "range": { "allOf": { "$ref": "Person.schema.json" } } } } } }Note: Forward and reverse property slots can be autogenerated from an
owl:ObjectPropertyschema:works_for a owl:ObjectProperty; rdfs:domain schema:Person; rdfs:range schema:Organization; owl:InverseOf schema:employee.