{
"@id" : "Model 1",
"@type" : "abc:model",
"entities" : [
{
"@id" : "Entity 1",
"@type" : "abc:entitiy",
"attributes" : [
{
"@id" : "Attribute 1",
"@type" : "abc:attribute"
}
]
}
]
}
So I think in part the issue is that the logic in RDFLib is not this:
https://www.w3.org/TR/json-ld11/#type-coercion
If no matching term is found in the active context, it tries to expand it as an IRI or a compact IRI if there's a colon in the value; otherwise, it will expand the value using the active context's vocabulary mapping, if present. Values coerced to @id in contrast are expanded as an IRI or a compact IRI if a colon is present; otherwise, they are interpreted as relative IRI references.
.
@_comment
for now
Hi all,
Mostly from curiosity, I'm trying to find a JSON-LD pattern that let's me use nested node identifier indexing so that URI paths match their corresponding JSON Pointer.
For example, suppose I have the following JSON-LD document, representing Oregon cities, and hosted at the root of https://oregon.gov
{
"@context": {
"@version": 1.1,
"@vocab": "https://rels.org/",
"@base": "http://oregon.gov/cities/",
"path":"@id",
"cities": {
"@id": "city",
"@container": "@id"
},
"neighborhoods": {
"@id": "neighborhood",
"@container": "@id"
},
"buildings": {
"@id": "building",
"@container": "@id"
}
},
"@id":"#",
"cities": {
"portland": {
"@context": {
"@base": "portland/neighborhoods/"
},
"neighborhoods": {
"laurelhurt": {
"@context": {
"@base": "laurelhurt/buildings/"
},
"buildings": {
"ice-cream-shop": {
"path": "/cities/portland/neighborhoods/laurelhurt/buildings/ice-cream-shop"
}
}
}
}
}
}
}
This document captures what I intended: the URI of "ice-cream-shop" is http://oregon.gov/cities/portland/neighborhoods/laurelhurt/buildings/ice-cream-shop. Its URI path is /cities/portland/neighborhoods/laurelhurt/buildings/ice-cream-shop, which also happens to be its JSON pointer within the document. This is fun, because it lets clients with no JSON-LD processing capability infer the path structure directly from the document.
The only trouble are those nested @contexts. Currently they get lost if I attempt to do any kind of framing, and I can't see how to "hoist" them up to the parent document's @context because they depend on the identifier index of the node they belong to. The current approach effectively uses nested @contexts to build up a stack of @base path fragments.
Is there any way to address this use case without relying on nested @contexts?
Thanks!
Thanks @gkellogg! I had tried this, but couldn't figure out how to make scoped contexts work in combination with node identifier indexing. If I added another city with a node identifier index like "eugene", I'd need a new @context detail, like
"neighborhoods": {
"@id": "neighborhood",
"@context": {
"@base": "eugene/neighborhoods/"
},
"@container": "@id"
},
But, like your sample shows (thanks for that!), we already have @base set to "portland/neighborhoods", so the two would be in conflict. I haven't been able to see how to "parameterize" scoped @contexts or @bases by named identifier indices.
I'm at peace this may not be possible outside of my original snippet, but wanted to check with the experts first :)
Does anyone have suggestions for improvement for porting this SHACL list validation example? I've used a nested context to to ensure the inner sh:path is parsed as a list (the outer sh:path is not):
{
"@context": {
"dash": "http://datashapes.org/dash#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"sh": "http://www.w3.org/ns/shacl#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"ex": "http://example.com/"
},
"@id": "ex:TrafficLightShape",
"sh:targetClass": {
"@id": "ex:TrafficLight"
},
"sh:property": {
"sh:path": {
"@id": "ex:colors"
},
"sh:property": {
"sh:datatype": {
"@id": "xsd:string"
},
"@context": {
"sh:path": {
"@container": "@list"
}
},
"sh:path": [
{
"sh:zeroOrMorePath": {
"@id": "rdf:rest"
}
},
{
"@id": "rdf:first"
}
],
"sh:minLength": 1,
"sh:minCount": 2,
"sh:maxCount": 3
}
}
}
Original TTL snippet is:
ex:TrafficLightShape
a sh:NodeShape ;
sh:targetClass ex:TrafficLight ;
sh:property [
sh:path ex:colors ;
sh:node dash:ListShape ;
sh:property [
sh:path ( [ sh:zeroOrMorePath rdf:rest ] rdf:first ) ;
sh:datatype xsd:string ;
sh:minLength 1 ;
sh:minCount 2 ;
sh:maxCount 3 ;
]
] .
TopQuadrant reference where the example came from: https://www.topquadrant.com/constraints-on-rdflists-using-shacl/