- From: Karol Szczepański via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Mar 2019 11:17:17 +0000
- To: public-hydra-logs@w3.org
> I don't think that's true. There is no sufficient tooling, especially in the browser to make > OWL compelling even to "hardcore users" Sorry, but JavaScript/TypeScript and browsers are not the only environments hydra is supposed to work with. Java has several reasoning tools that works with RDFS/OWL fine, thus we should not disable those. >Why not? It fits the purpose. Why should we invent another vocabulary that does the same things, > just worse / not as complete as SHACL? OWL is way more complex than SHACL to my knowledge and has many constraint related constructs. The thing is - It's to complex for simple uses. I just don't want to elevate one external (in relation to hydra) vocabulary or the other. >SHACL is pure RDF, isn't it? So I can't quite follow why they wouldn't use it? It is written in RDF, but it is somehow invisible for RDFS/OWL reasoning mechanisms. >Nevertheless my focus is on real-world APIs and helping Web developers to build better > APIs using Linked Data, that are not aware of it's strength right now. Don't forget hydra aims also to be useful for automated (AI?) clients (machine only) > SHACL is not only able to describe the expected data shapes, but also perform validations, > which is really helpful. So are OWL and reasoners. Just to be clear - I want to support neither SHACL nor OWL in any way - I just want to ensure hydra is as generic and not-restricting as possible. I wouldn't also to see multiple hydra dialects (i.e. this API uses SHACL and another OWL and no generic client would work with both). -- GitHub Notification of comment by alien-mcl Please view or discuss this issue at https://github.com/HydraCG/Specifications/pull/187#issuecomment-474787642 using your GitHub account
Received on Wednesday, 20 March 2019 11:17:19 UTC