- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 13 Feb 2015 13:25:09 +1000
- To: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
A random thought before the week end: Can this WG (please!) produce two separate standards? 1) An RDF vocabulary similar to the original LDOM proposal 2) The ShEx Compact Syntax aiming at the data reuse scenarios We already have RDF Schema. We already have OWL. We would already have a third language (LDOM or whatever). Why not have a forth language? The situation in very similar to XML Schema vs. DTD. vs RELAX-NG. They all solve similar problems, but from different perspectives. We are currently trying to mix different paradigms together and risk producing something that nobody will be happy with. People with OO background will wonder what the fuzz is about this parallel structure called "Shapes", raising the implementation costs and creating a mix of parallel semantic webs. And ShEx people don't want to worry about the interactions of the various triple models at all - instead have the ShExC files live outside of the triple store. And that makes sense because even if you introduce ldom:instanceShape to separate shapes from classes, you'd still run into conflicts with other ShEx models that also happen to use ldom:instanceShape. The only proper solution here is to not have triples in the first place. Another constant source of conflict will be the role of SPARQL. The ShEx camp seems to be more concerned about the balance of expressivity and complexity, while the SPIN camp has plenty of use cases where expressivity is the main concern. Furthermore, a SPIN-like LDOM can more easily be combined with existing RDFS and OWL ontologies, filling gaps in that space. We have a handful of ShEx supporters in the WG. I am sure they could turn their Member Submission into a formal spec quite rapidly. From an LDOM point of view we have plenty of stuff already implemented, and I'd be happy to wrestle and collaborate with anyone to flesh out the open details. The Requirements document is already being split into "Property constraints" and "Complex constraints", so both camps can harvest from the same catalog of requirements. We can also share test cases and produce a small document explaining how to map from one language to another. But the aforementioned reasons and the endless discussions over the last half a year provide plenty of arguments that justify why the WG chose to create two languages. Why would this separation of deliverables not work? Thanks, Holger
Received on Friday, 13 February 2015 03:25:54 UTC