alelom
commented
1 year ago In the proposed structure, the name of the property (Curves) does not appear anywhere. This would make the deserialization impossible. For example, an alternative that would allow to deserialize is:
### https://uni-stuttgart.de/c96b157f-e8a7-26fc-af6a-d8409a8cf95b
<https://uni-stuttgart.de/c96b157f-e8a7-26fc-af6a-d8409a8cf95b> rdf:type owl:NamedIndividual ,
:BH.oM.Geometry.PolyCurve.Curves, rdf:Seq;
rdf:_0 <https://uni-stuttgart.de/09e133ce-2e99-ae92-45fb-1d0477f80508> ;
rdf:_1 <https://uni-stuttgart.de/e0bb1765-74da-6acc-1f59-452e29f5a7ff> ;
rdf:_2 <https://uni-stuttgart.de/68205cc2-5517-4ecb-21a0-40849eef35c2> ;
rdf:_3 <https://uni-stuttgart.de/61819389-fb27-ffc5-4f31-966d86cf53f7> .However, this is not correct from a T-box alternative, I think? @DiellzaElshani I think you need to clarify what the best option is (perhaps with @danielhz ) and then we can change the behaviour if we think it's useful. I would not categorize this a as a bug but as a feature, because the code behaves as previously agreed (it's not a malfunction of the code, but a modification in its working).
DiellzaElshani
polnischfrosch
Description:
Apparently the way we handle lists is wrong, because objects that have lists should be type rdf.Seq. In this case we could query elements of the sequence. Currently it appears that we created a new property name Seq, and rdf:_0,1,2 etc. are not related to the Seq.
Currently:
This approach leads to the generation of properties named rdf:_0, rdf:_1, rdf:_2, and so on, which are not inherently associated with the rdf:Seq structure.
Afaik, the ideal structure should look like:
This proposed structure ensures that the sequence is associated with the correct type (rdf:Seq) and retains the proper order in querying, and also aligns better with the RDF specifications.
Consequently, TBox should be updated too. I need to think about the best way to represent it.
But the key part is that such Nodes are classified as rdf:Seq.
Steps to reproduce:
Expected behaviour:
Test file(s):