search

BHoM / RDF_Prototypes

Research project of the Cluster of Excellence "Integrative Computational Design and Construction for Architecture" (IntCDC) https://www.intcdc.uni-stuttgart.de/ **Project Name**: Knowledge Representation for Multi-Disciplinary Co-Design of Buildings. https://www.intcdc.uni-stuttgart.de/research/research-projects/rp-20/
GNU Lesser General Public License v3.0
9 stars 4 forks source link

Should `Base64JsonSerialized` be ontologically equivalent to `xsd:string`? #34

Closed DiellzaElshani closed 2 years ago

DiellzaElshani commented 2 years ago

Description:

jsonSerialized must not be equivalent to xsd:string.

comments from Daniel

Steps to reproduce:

Expected behaviour:

Test file(s):

alelom commented 2 years ago

Sure we can remove the equivalence, but why?

JsonSerialized is effectively simply a string. The content of the string is some JSON text encoded in base64, but it remains a string.

Again, no problem in removing the equivalence, but perhaps @danielhz could clarify the reasoning behind this?

danielhz commented 2 years ago

The equivalence jsonSerialized ≡ xsd:string implies two inclusions, namely jsonSerialized ⊑ xsd:string and xsd:string ⊑ jsonSerialized. There is no problem with the first inclusion, but there are with the second one. Not every xsd:string is a valid jsonSerialized. For instance, the string "{ \"a\": 1" is not valid because a parenthesis is missing.

alelom commented 2 years ago

Thanks for clarifying that @danielhz. Is there a way we could specify jsonSerialized ⊑ xsd:string only?

danielhz commented 2 years ago

To my knowledge, OWL does not provide a way to define hierarchies over data types. So, you cannot say that xsd:integer is a sub datatype of xsd:decimal with OWL. This hierarchy is defined for the XML data types (see https://www.w3.org/TR/xmlschema-2/#built-in-datatypes) but you cannot use OWL to describe this hierarchy. You cannot use the predicates owl:sameClass and owl:subClassOf between data types because they are not classes. Furthermore, I think that jsonSerialized ⊑ xsd:string is also wrong because the set of JSON documents is not included in the set of strings. The reason is the same for the fact that datatype xsd:integer is not a subtype of xsd:string. Although you can express numbers as strings, you cannot say that "9"^^xsd:integer is also of type xsd:string. The hierarchy of data types is not determined by the way literals are encoded, but by the elements literals represent. "9"^^xsd:integer represents the number 9, which is not a string.

alelom commented 2 years ago

Thanks, you convinced me. I'll remove the equivalence.