Re: comparing to OWL and SPIN

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).

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.

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.

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.

peter


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 Thursday, 17 July 2014 13:25:13 UTC