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

RE: comparing to OWL and SPIN

From: Dam, Jesse van <jesse.vandam@wur.nl>
Date: Mon, 21 Jul 2014 11:43:49 +0000
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
Message-ID: <63CF398D7F09744BA51193F17F5252AB1641E981@SCOMP0936.wurnet.nl>
Hi,

I would like to thanks you and the others for the useful discussions. I feel ashamed that I did not know about ICV.
I need some time to think about and look at the many points given, before I continue on the discussion.

Here my answer on your mail.

>It certainly does appear that there are mappings between ShEX, OWL, and SPIN.
>I'm not sure about that any of these mappings are total, but they may be.
>Even if there are inclusion relationships, this does not imply that the
>simpler setup is faster (in theory or in practice).
Sorry if you misunderstood my statement, I did say it has to be true, but is something that could be tested. I could be that the Regular Expression derivatives algorithm, although much less expressive then OWL, is outperforming the OWL reasoners.  Only some research and testing will give an useful answer, but certainly something nice to consider and test.

>Your assertion that shapes and shape properties is better for users is nothing
>more than assertion so far.  Do you have anything to back this up?
>OWL has disjunction, so you can say
>A <= all ex:samepred1 (B or E)
>which is even better than the ShEx version you give.

No I do not have, expect the personal experience related to learning none computer scientist users to use the semantic technologies for their purposes. For them some of the OWL features are complex and not directly useful for my users. I must admit I could try to use the Manchester syntax on my users.

>Note that I am not saying that an OWL reasoner will do constraint checking
>directly out of the box, just that OWL (and RDFS) semantics (and syntax) can
>be used to specify constraints.  An OWL-based constraint checker would do
>things like reporting errors, just as any other constraint checker does.
That was exactly one of the problems I had, where do I tell the reasoner to do inference of new triples where should it report an error. However I was not aware of ICV. So I will check it out and see how I can use and how relates to SHEX.

>I don't know why you say that OWL does not support graphs.  OWL models are
>graph-like, and can be written as RDF graphs.  In some profiles of OWL there
>is always a minimal model, and the graph for this minimal model can be used to
>give the meaning of an OWL knowledge base.
What I refereed here was the use of writing an ontology over different RDF graphs/contexts. So I can see for example that a certain property should reference a RDF graph, which should be validating a given set of OWL axioms. Or for example I can see that a certain triple should/can have some context attached to it, which should also validate. 
An example use case would be when I put provenance for a certain triple.
:geneA :regulates :geneB :someprovenance
:someprovenance :ref :paper1
:someprovenance :evidence :experiment

Thanks,
Jesse van Dam


On 07/17/2014 05:46 AM, Dam, Jesse van wrote:
> Hi Peter,
>
> Thanks for your comment and suggestion. Now it seems for me that we can express SHEX in OWL, which comes to very interesting comparison if start comparing SHEX, OWL and SPIN.
>
> Note that the statement I put here are not tested or verified so they could be wrong. (Please let me know if I am wrong)
>
> We can express a SHEX schema(if no semantic actions are used) as an OWL ontology.
> We can express an OWL ontology as a SPIN file.
> The reverse options are not possible or will lead to information loss.
>
> Validation algorithms
> SHEX -> Regular Expression derivatives (fastest - most limited)
> OWL -> OWL reasoners (faster - limited) (multiple profile exists)
> SPIN -> SPARQL query engine (slowest - most powerful)
>
> Expressing an OWL ontology as a SPIN file, however, it will becomes performance wise a problem as OWL is mathematically 'optimized'(lots of research has been done on that topic).
> The same thing will probably happen if we try to validate an SHEX schema as an OWL ontology on a OWL reasoner.
>
> If true this is true then this would be a reason to have SHEX.
>
> Beside a possible performance advantage, there could be another advantage.
> SHEX is oriented on Shapes and Shape Properties(Property per shape), whereas OWL is oriented on (Restriction) Classes and Properties.
> Orientation on (Restriction) Classes and Properties is a logic and the best thing to do when working in the world of reasoning.
> However if we look from user point of view, which would like to understand the structure of database or interface of a service then an orientation on Shape and Shape Properties is better. This is what a user needs when he wants to write some queries for a database as noted earlier on by me.
> Translation from SHEX to OWL will be strait forward (if possible) however the reverse translation is not (if we try do translate the items that can be translated back). For a both a machine and human user it is difficult to do.
> I could be wrong it this statement, but then there comes the problem of many people not properly defining there ontologies if at all, because it is rather complicated and time consuming to do.
>
> So SHEX could actually be a simple language for users to start defining there schema, which can then translated into an OWL file upon which users can start further extending there OWL if they want to do so. Maybe SHEX can be also a new OWL profile.
>
> Here is one of the examples why I find it hard to read an OWL ontology to understand the structure of a database.
> Shape expression
> A {
>    (ex:samepred1 @B | ex:samepred1 @E) #its clear is either referencing B or E
> }
> C {
>    ex:samepred1 @D
> }
> In OWL that would be
> Class A -> ex:samepred1 -> Class B
> Class C -> ex:samepred1 -> Class D
> A <= all ex:samepred1 Extra
> C <= all ex:samePred1 D
> Class B -> rdfs:subClassOf -> Class Extra
> Class E -> rdfs:subClassOf -> Class Extra
> Here have an extra class 'Extra' for which it is not clear whether is created for making the ontology work or is an actual Concept in my database.
>
> A third reason would be that a SHEX validator will give other 'error' reports (details yet to be defined) if something is mismatching then what a OWL reasoner would do.
>
> Concluding things we could do for testing:
> * Try to make translation tool from SHEX to OWL and see if its possible
> * Try to make translation tool from SHEX to SPIN and see if its possible
> * Perform some performance test and see the results
>
> I must note however that OWL does not support graphs.
>
> I think this is an interesting discussion.
>
> Thanks,
> Jesse van Dam
>
> ________________________________________
> Van: Peter F. Patel-Schneider [pfpschneider@gmail.com]
> Verzonden: donderdag 17 juli 2014 6:48
> Aan: Dam, Jesse van; public-rdf-shapes@w3.org
> Onderwerp: Re: Shapes/ShEx or the worrying issue of yet another syntax and  lack of validated vision.
>
> On 07/16/2014 06:16 AM, Dam, Jesse van wrote:
>> Hi,
>>
>> This is my opinion and comments based on some off the concerns raised by Jerven Bollemand and Holger  KnubLauch.
>
> [...]
>
>> If we look at RDFS and OWL, I think there are good reasons not to include that into SHEX. RDFS and especially OWL are well designed standard for doing reasoning, however, there are in no way there were ever intended as language to describe a database structure or to be used as Schema language for validation. It is a pitty that many people misused these standard for this purposes or purposes alike. For further reasons I would advice you to read the conclusion of this paper (http://arxiv.org/pdf/1404.1270v1.pdf).
>> Another thing you can not do in OWL is to define the following:
>> Type A -> ex:samepred1 -> Type B
>> Type C -> ex:samepred1 -> Type D
>> If you would define this in OWL you will also get, because OWL is property oriented and a property can only define a range and domain
>> Type A -> ex:samepred1 -> Type D
>> Type C -> ex:samepred1 -> Type B
>> Which is something we do not want.
>
> Why do you say that?  OWL includes many constructs that are local.  Here you
> can use allValuesFrom, as in
>
> A <= all ex:samepred1 B
> C <= all ex:samePred1 D
>
> Why would this not work for you?
>
> [...]
>
>> Greetz,
>> Jesse van Dam
>
> peter
>

Received on Monday, 21 July 2014 11:44:21 UTC

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