Fails on xsd:dateTimeStamp rdfs:subClassOf xsd:dateTime. Howto enforce inheritance? #167
Comments
|
Hi @volkerjaenisch It is stipulated in the SHACL specification that all ontological relationships required for the successful validation of a datagraph against a Shape, must exist within the datagraph at the time of validation. In other words, if the relationship of I suspect you know this already, because you asked about injecting the inheritance information into PySHACL. PySHACL does have some very basic relationships baked into the code (eg, those found in RDF and RDFS) but that does not extend to XSD subclasses. If it is not possible for you to have ontological definitions in the datagraph (eg, if the data in the datagraph is pulled from a separate closed system), then you can use PySHACLs 3-file method. Where you have the SHACL Shape file, and Extra ontology file, and the data graph. Note, this issue has encouraged me to look into whether it would be wise to extend the hardcoded relationships in PySHACL to include some common XSD relationships, like this one, for convenience for users. |
|
Dear @ashleysommer ! Thank you so much for shedding light on all these topics. I already tried to inject the additional ontological information (into the data) but to no avail. Probably I did something wrong. bin/pyshacl -s shapes/dcat-ap_2.1.1_shacl_shapes.ttl -im -e shapes/dcat-ap-de-imports.ttl data/datetimestamp.ttl datetimestamp.ttl The result: The offended shape: From the discussion at SEMICeu I think that I learned that the data types xsd:dateTime etc. are no RDF entities and therefore not a concern of SHACL. But I think that this depends strongly on the implementation of the SHACL engine.
This would be really great. Cheers, |
|
Apologies for butting in, but something caught my eye about @volkerjaenisch 's request. My understanding was that there is not a way to declare a datatype a "Subclass" or "Subdatatype" of another datatype. OWL has a way of defining restricted datatypes (OWL 2 Syntax, 9.4; see the "Show RDF in Examples" button to see Turtle alongside the functional syntax), which is the closest I've seen to establishing a hierarchy. I'd thought the only way to handle wanting to permit two datatypes using SHACL, where one looks like a "subdatatype" of another, was to use an |
|
@ajnelson-nist The problem that I face is that we have to use SHACL files provided by the EU, that we cannot alter. This is because the EU will use these SHACL files to validate the data files we provide the EU with. I have opened a GH issue at the EU to tackle this problem. And you are right: The EU shape uses indeed But I think that we all here agree that this is a strategy with a limited future. Since someone will come up with the next type that is derived from xsd:dateTime. E.g. xsd:dateTimeJulianDay . The idea behind this shape is to check that the given information is typed with a xsd:<date, time type>. So concerning the idea of the shape any dateTime type fullfills the shape. If there would be inference or inheritance working, a simple check against the xsd:datetime base class will suffice to implement the idea. This is quite common in other languages. In e.g. Python isinstance(obj, list) checks if the given object is of a class that is derived from class "list". This is IMHO what is needed in SHACL. Cheers, |
I disagree on this point, but fortunately I think I disagree in a way that causes us all less work at the end of the day. The EU shape you cited uses a few of the time-relevant types used in XML Schema, defined in a document last updated in 2012, which had several rounds of editing from a version posted in 2004: https://www.w3.org/TR/xmlschema11-2/ So, I think concerns of this being a "Limited-future" strategy can be comfortably disregarded. New time types seem unlikely to appear with a surprising speed. And, if they should appear upstream, the effect would likely propagate at a pace downstream through RDF, and then SHACL, and then the EU shape maintainers where everyone can comfortably plan to adapt. For your use case with Again, I suggest augmenting the SHACL's datatype constraints cite a dependence on the SPARQL 1.1 I'm happy to be informed of counter-examples to any of my above points if someone can cite me a response, but to date that is what I have observed. So I think this issue is outside the scope of pySHACL and of SHACL. One potential counter-example might come from this definition in the RDFS Entailment Rules appendix, where literals are assigned class-membership using |
Dear RDFlib developers!
At first thank you so much!
Without your code our Open-Data Portal https://datenadler.de would never have taken flight. We do not use CKAN, we programmed from scratch. Currently we are the second most populated Open-Data portal in Germany.
But now we need SHACL. pySHACL generally runs fine but I seems that we are running into some detail problems.
This may be an exotic case. It does not work on other SHACL processors, too. So it may be a limitation of SHACL itself.
So this is not a bug report but more stating of a SHACL fact.
Given the following data
and the following shape
OK, the files are a bit more complex but it boils down to that.
Is it possible with pySHACL to inject the inheritance information:
xsd:dateTimeStamp rdfs:subClassOf xsd:dateTime .
If so, how?
Any help appreciated.
Cheers,
Volker
The text was updated successfully, but these errors were encountered: