SHACL2XSD possible?

[gatemezing]

Hello,
I find this work very interesting. Quick question - do you plan to have mappings from SHACL to XSD? TIA

[andimou]

at some point yes 😅

[gatemezing]

Thanks @andimou . What can help to speed up the process? some use cases? we do have use cases

[andimou]

We're always happy if we have use cases, thanks @gatemezing!! I'll follow up with you by email.

[MathiasVDA]

Could the email exchange be summarized here? :)

[MathiasVDA]

I've been looking into this. I can probably create a first version with pull request later today. @dachafra @andimou @xuemduan , is this something you want to include in this project or would you prefer that I create (and maintain) a shacl2xsd repository myself?

[xuemduan]

Hi @MathiasVDA, may I know your general idea about SHACL2XSD? Are you expecting the SHACL2XSD to target all SHACL shapes as input or just the SHACL shapes generated by XSD2SHACL?

[MathiasVDA]

I would limit the scope to what the current output is limited to of xsd2shacl. SHACL goes waaaaaay beyond xsd.

A good baseline could be: everything in the comparison folder should be able to be converted from xsd to shacl and back again.

[MathiasVDA]

And I would focus on producing correct xsd equivalents. Not exactly the same xsd file as the source. Some data is not transferred from xsd to shacl so cannot be reversed either. Plus, xsd has a lot of structural freedom. There is not 1 way to do things. So there could be multiple possible solutions for a shacl->xsd instance

[xuemduan]

Thank you! Limiting the scope to XSD2SHACL is a good start and we would be happy to have it as part of this project.
We have not yet started the full work on SHACL2XSD is because we are concerned that limiting the scope to XSD2SHACL will limit the applicability to real-world cases since the users might follow different ways to construct RDF graphs from XML (the additional post-adjustment module of XSD2SHACL helps the generated SHACL shapes to be applicable to all real-world RDF graphs constructed from XML via RML mappings), but this SHACL2XSD limiting to XSD2SHACL itself is very interesting as a start and for research purposes also:)

[MathiasVDA]

we got to start somewhere :)

[MathiasVDA]

One limitation that I see now that I'm working on it, is that the SHACL produced by xsdtoshacle doesn't contain the difference between and (I never understood why it's relevant to put children elements into a specific order for xml either...). So the shacl2xsd will always need to use the

[gatemezing]

Could the email exchange be summarized here? :)

That email is still to be sent by @andimou :) - I'm also waiting for it.

[xuemduan]

One limitation that I see now that I'm working on it, is that the SHACL produced by xsdtoshacle doesn't contain the difference between and (I never understood why it's relevant to put children elements into a specific order for xml either...). So the shacl2xsd will always need to use the

Whether the order of XML is important for RDF and SHACL depends on the XML2RDF assumption. Before we see the RDF or the way users constructed RDF (e.g., RML mappings), we never know how the users do XML2RDF, we can only assume how users do. If we assume that XML2RDF process will preserve the order of XML in RDF in a certain way (e.g., rdf:Seq), then we need to handle it in the generated SHACL correspondingly. If we assume that XML2RDF will ignore the order of XML, then SHACL can also ignore it.

[MathiasVDA]

Small update, I'm not finished with the shacl2xsd yet. The comparison ttl files that still need some care are:

• attributeGroup
• complexType (though small things)
• extensions
• unions

So the easy part is done, now just the hard part

Progress in this feature branch: https://github.com/Matdata-eu/XSD2SHACL/tree/feature/shacl2xsd