- From: Jose Emilio Labra Gayo <jelabra@gmail.com>
- Date: Thu, 17 Jul 2014 06:39:52 +0200
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: Simon Spero <sesuncedu@gmail.com>, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>, "public-rdf-sha." <public-rdf-shapes@w3.org>
- Message-ID: <CAJadXXLqt045CibRL+YKKVtVCDgaRMshddhWF-GTFkbfk4QqnA@mail.gmail.com>
On Thu, Jul 17, 2014 at 5:48 AM, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote: > I don't think that this is a helpful way of describing the problem. > I think there are different problems and needs and different strategies to solve some of them. My view is that there are two interconnected notions in play here. The > first is determining the consequences of some representation of > information. The second is determining whether some representation > explicitly represents some information. Reasoners provide implementations > of the first notion. Constraint checkers provide implementations of the > second. > Maybe, my notion of shape checking is more low level than your notion of constraint checker. You say that constraint checkers determine whether some representation explicitly represents some information...but maybe that information is not at the same level than the information the reasoner is working on. I mean, the reasoner is usually working with domain concepts, while shape checking is working with RDF graphs...It is just trying to check if some RDF graph contains some triples with some specific shape. It is possible that it will not be helpful in some use cases, but I have found that when you are trying to integrate RDF graphs from different linked data portals, you would like to have some description of the contents of those RDF graphs so you can automatically check if you are really retrieving those triples, and when you publish RDF graphs or work with a team of developers you would like an easy way to tell them which triples they have to publish in a way that they can validate if they are really producing the required triples. For these use cases, I have found that shape expressions are a very good tool. That's all exceedingly general so far, so let's make it a bit more > concrete. Let's say that our representation language is triples, and that > this language has meaning as in RDFS or OWL. In some cases here, but > certainly not all, a reasoner can operate by adding more triples to a > graph, namely triples that are consequences of the triples in the graph. > How constraint checkers work is undetermined as of yet, because the > language of constraints has not yet been given. Let's go with something > simple - constraints that require instances of particular classes to > explicitly have certain information associated with them. A constraint > checker would then have two parts - one that determined which objects > belonged to a class and the other that determined whether the graph > explicitly contains the required information. > > Where does shape checking fit here? Nowhere yet. I may be that the > second part of the constraint checker is a shape checker. However, it may > not be. To fix on shape checking as even a way to determine whether a graph > contains enough information to be suitable for use before figuring out what > sorts of information checking is needed is putting the cart before the > horse. To fix on shape checking as the only way is having a cart with no > horse. > That's why I think shape checking should not be the "only way". Maybe, it is just a way to describe the shapes of horses and carts before processing them. To my mind, shape checking is like checking whether the least significant > bit of a memory loacation is zero or one. Sure you can implement even and > odd testing this way, but it's not the right way of specifying the problem. I think you are right and Shape checking is more low level than constraint checking in general. However, I also think there are plenty of practical applications where one would like to have some way to declare the shapes of RDF graphs in a easy and automatically verifiable way. Best regards, Jose Labra > > > > peter > > > > On 07/16/2014 07:45 PM, Jose Emilio Labra Gayo wrote: > >> In my opinion it is better to separate the tasks of a reasoner and the >> tasks >> of a shape checking service. A reasoner takes a graph and inserts more >> triples >> in the graph, while a shape checking service takes a snapshot of a graph >> and >> checks its shape. The snapshot could be taken before the reasoning stage >> or >> after. >> >> I think that mixing the semantics of both can add more complexity to the >> shape >> cheking service than necessary. As I previously said, the goal of Shape >> Expressions is to be a simple language that can describe and validate the >> shape of RDF graphs having RDF graphs as the domain of discourse, instead >> of >> the domain concepts that are the domain of discourse of reasoners. >> >> In my opinion, this simplicity is a good design choice with a lot of >> potential. Of course, this is not to say that it will cover all the use >> cases >> of RDF validation. But most of those use cases could be covered in >> combination >> with the Shape Expressions language. >> >> Best regards, Jose Labra >> >> >> On Wed, Jul 16, 2014 at 11:30 PM, Simon Spero <sesuncedu@gmail.com >> <mailto:sesuncedu@gmail.com>> wrote: >> >> How would you compare the semantics of this to those of ICV? >> >> Thanks, >> Simon >> >> >> On Wed, Jul 16, 2014 at 10:12 AM, Jose Emilio Labra Gayo >> <jelabra@gmail.com <mailto:jelabra@gmail.com>> wrote: >> >> If I understand your question, I think what you are asking is out >> of >> the current ShEx scope but it can be handled by other tools or it >> could be added to ShEx processors also. >> >> I mean, ShEx just checks the shape of an RDF graph...that graph >> can be >> the original graph or it can be the result of applying a reasoner >> to >> the original graph, in which case, it would check the original >> graph >> plus the inferred triples. >> >> An implementation of ShEx could do RDF Schema or OWL inference >> before >> applying ShEx so it could check the shape of the inferred graph >> instead of the original one. At this moment, I didn't incorporate >> it >> in Shexcala but it would not be difficult to add a flag to do it. >> >> Best regards, Jose Labra >> >> >> >> >> On Wed, Jul 16, 2014 at 3:38 PM, Dimitris Kontokostas >> <kontokostas@informatik.uni-leipzig.de >> <mailto:kontokostas@informatik.uni-leipzig.de>> wrote: >> >> Hi all, >> >> I noticed that at the moment you do not handle sub-classes & >> sub-properties. >> In a previous thread you mentioned that ShEx want to stand >> somewhere like one step above syntactic validation so is this >> something out of the ShEx scope? >> >> This can be easily achieved with SPARQL1.1 and property paths >> - >> when the shape is evaluated in SPARQL (to be clear). >> However, it needs the schema to get the relations. >> Ideally this could be enabled by default in ShEx and a special >> directive could point to the schema(s) >> Or a special notation could mark if we want to match strictly >> <Issue> or any subclass >> such as: <CodingIssue> a owl:Class; rdfs:subClassOf <Issue> . >> >> Any thoughts, comments on this? >> >> Best, >> Dimtiris >> >> -- >> Dimitris Kontokostas >> Department of Computer Science, University of Leipzig >> Research Group: http://aksw.org >> Homepage:http://aksw.org/DimitrisKontokostas >> >> >> >> >> -- >> Saludos, Labra >> >> >> >> >> >> -- >> Saludos, Labra >> > -- Saludos, Labra
Received on Thursday, 17 July 2014 04:40:41 UTC