Open rorlic opened 5 months ago
A little investigation shows that every relative URI, without setting an @base
first, receives a file://
scheme. In fact, this is how the Jena model is parsed and then parsed back to a string:
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix ldes: <https://w3id.org/ldes#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix tree: <https://w3id.org/tree#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
<file:///touristattractions/shape>
a sh:NodeShape;
sh:closed false;
sh:targetClass <http://purl.org/dc/dcmitype/Collection> , <https://schema.org/TouristAttraction> .
<file:///touristattractions/view>
tree:viewDescription [ tree:fragmentationStrategy [ a tree:ExampleFragmentation;
tree:property "ldes:propertyPath"
]
] .
<file:///touristattractions>
a ldes:EventStream;
ldes:timestampPath prov:generatedAtTime;
ldes:versionOfPath dcterms:isVersionOf;
ldes:view <file:///touristattractions/view>;
tree:shape <file:///touristattractions/shape> .
Because of the way eventstreams and views are handled in the server, the file://
scheme is just ignored. To be more detailed, this happens because of the .getLocalName()
calls that happen to retrieve the collection or view name. However, this is not the case for shacl shapes, as they stay RDF/Jena models in the code base and in the db. Further investigation on how to fix this issue needs to happen
Describe the bug When ingesting a shacl shape which is identified with a relative URI (instead of a blank node) then the shacl shape is identified in the LDES using a
file://
scheme.To Reproduce Steps to reproduce the behavior:
Seed the LDES server with the following definition:
and notice that the shape is incorrectly named:
Expected behavior The shacl shape should be identified by:
<http://localhost:9003/touristattractions>/shape
instead of<file:///touristattractions/shape>
.