W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > July 2014

Re: Shapes - sub-classes / sub-properties

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Wed, 16 Jul 2014 20:48:18 -0700
Message-ID: <53C74782.40107@gmail.com>
To: Jose Emilio Labra Gayo <jelabra@gmail.com>, Simon Spero <sesuncedu@gmail.com>
CC: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>, "public-rdf-sha." <public-rdf-shapes@w3.org>
I don't think that this is a helpful way of describing the problem.

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.

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.


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.


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
Received on Thursday, 17 July 2014 03:49:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:39 UTC