-
Notifications
You must be signed in to change notification settings - Fork 2
"You say Schemata, I say Schemas" #8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I would be interested to be another chair to the discussion since this topic is of great interest to the Web of Things Working Group whose Thing Description REC makes use of all three categories. It would be also nice to avoid conflicts with other Web of Things related breakouts, such as one planned by @ashimura regarding smart cities. |
As a follow-up, here are the takeaways:
@pchampin can you get the presentations from the other presenters? For the record, there were 4 presentations in total: Pierre-Antoine, me, TreeLDR and LinkML |
Hi! We formalize the meta-model in a subset of Python language, parse that meta-model into an intermediate representation, and, based on that, generate all the downstream artifacts (SDKs in different languages, JSON Schema, XSD, RDF+SHACL, etc.). Probably it would be best if we schedule a phone conference and I present you the approach, but here are some entry points if you already want to have a look at what we did so far. https://www.researchgate.net/publication/374055610_Maturity_Evaluation_of_SDKs_for_I40_Digital_Twins For more background on code generation, please contact me on my email, as the related paper has been submitted and accepted at IECON 2023, but not published yet. A bit outdated repository of design docs is available here: For a list of all the things we generate, see: The meta-models live in: The main generator lives in: |
Thanks @mristin for joining the discussion! As you wrote, it would be absolutly interesting to learn from your experiences! @pchampin, @egekorkan - what do you think? |
Thanks @mristin for the inputs. Your use case is also relevant. Our decision in TPAC was to propose a new community group such that these discussions can be had together. Would you be interested in participating? |
Certainly! Best you contact me via email or via Linkedin for the next steps so that we do not spam this issue. |
@cmungall @pchampin @egekorkan I've subscribed for w3c/breakouts-day-2024#15 @mristin and @wiresio I'm very interested in AAS use cases based on semantic technologies. |
@VladimirAlexiev - Always happy to brainstorm about new ideas! Will send you an email for this. Would also be great if you could join the breakout session mentioned above. |
Uh oh!
There was an error while loading. Please reload this page.
Session description
A large variety of schema languages exist, defined inside or outside of W3C; to name a few: RDF-Schema, OWL, SHACL, ShEx, XML-Schema, JSON-Schema... Each of these languages have been favored by different categories of users, who in turn ignore, neglect, sometimes even despise the other languages, deemed "too complicated", "less powerful" or simply "not fit for purpose".
It might be tempting to consider that any schema language is worth any other, and that the "best" one is a matter of technological preferences. We argue on the contrary that these languages differ in their core purpose, and should be seen as complementary rather than competitors. More precisely:
ontology languages such as RDF-Schema and OWL focus on the conceptual modelling of the domain,
shape languages such as SHACL and ShEx focus on the logical modelling of the data,
structural schema languages such as XML-Schema and JSON-Schema focus of the physical modelling of exchange formats.
Sticking to one schema language to cover all these aspects is therefore suboptimal. Creating bridges between their user communities, to allow cross-fertilization and combined use, is a promising approach.
But it is also challenging, because it creates the need to maintain consistency across schemas at different levels. We will present different tools and methods that have been proposed to deal with this problem, and discuss the standardization opportunities in this area.
Session goal
We will discuss the complementarity of various schema languages, and which tools are available (or missing...) to make them work together.
Additional session chairs (Optional)
@egekorkan
IRC channel (Optional)
#schemata
Who can attend
Anyone may attend (Default)
Session duration
60 minutes (Default)
Other sessions where we should avoid scheduling conflicts (Optional)
No response
Estimated number of in-person attendees
Don't know (Default)
Instructions for meeting planners (Optional)
Late afternoon slot as some of the presenters will be presenting remotely from the US west coast.
Agenda, minutes, slides, etc. (Optional)
The text was updated successfully, but these errors were encountered: