- From: Arnaud Le Hors <lehors@us.ibm.com>
- Date: Mon, 12 Dec 2016 20:51:13 +0100
- To: Dean Allemang <dallemang@workingontologist.com>
- Cc: public-rdf-shapes@w3.org
- Message-Id: <OF35BD56A3.7CD661CC-ONC1258087.006BA152-C1258087.006D0B76@notes.na.collabserv.c>
Everybody, Please. There is no point in trying to convince people that your favorite technology is better than the other. I've seen the same happen with XML Schema and Relax NG. In the end we have both and they are both used. My guess is the same will be true of SHACL and ShEx and this is totally fine. My hope was to make both of them W3C Recommendations. -- Arnaud Le Hors - Senior Technical Staff Member, Open Web & Blockchain Technologies - IBM Cloud From: Dean Allemang <dallemang@workingontologist.com> To: public-rdf-shapes@w3.org Date: 12/12/2016 07:18 PM Subject: Re: Why not adopt ShEx? (was Re: Enough already) Sent by: deanallemang@gmail.com Sorry, but I see zero advantages of ShEx over SPIN/SPARQL. Why would I want to lock my software into a new non-standard syntax with close to none adoption, when I can simply use the query engine to validate constraints? I couldn't agree more. In FIBO, we have been looking for a constraint language to help us make definitions that go beyond the capabilities of OWL. I presented these at the inaugural meeting of the SHAPES group a couple years ago. It is easy to specify them in SPARQL, and we have done so (and I did the same in SHACL, now that there is a write-up of how it works). When we move from our conceptual ontology to something operational for a Proof of Concept, some vendor is always involved. That vendor (different one for each PoC) always has an RDF store somewhere in their stack. They can always consume OWL (though often through a rule engine interpretations via OWL2RL). For rules/constraints that go beyond OWL, we have to work out some way to give them the rules. SWRL? Some of them can manage that. RIF? Everyone knows what it is, but few can handle it out of the box. Other rule systems have varying degrees of uptake. But one thing all the triple stores can manage is SPARQL. "How about if I give you the constraints in SPARQL?" the answer is always, "Oh, sure, that works". Because they are all triple stores, and they already do it. This doesn't mean that we have to do this in SPARQL, but it does mean that if we have that option, we shortcut a lot of work to get to our Proofs of Concept. In the end, I'm just re-iterating what Martynas has said much more succinctly, but in the context of a whole industry effort (FIBO) and a selection of vendors who want to work with us. Dean
Received on Monday, 12 December 2016 19:51:50 UTC