RE: shapes and classes: different

< In ShExC the mere presence of the square shape triggers recognition so here  at least there is a difference.>

Does it mean that in ShExC everything is validated against every shape present? I think such overzealous validation is problematic and more fine-tuned controls are needed. In any case, why does it matter that a decision to validate everything if a shape is present was made by ShExC? 

I believe we have settled for the standard to have three principal ways of "triggering" validation: per type/class, per resource/node and global/static. If this is not a complete list, other methods can be added, but this working group has full control over what they should be.

<Similarly, the two versions of square have different consequences in OWL.>

Why does it matter for this new standard? It would seem to be fairly orthogonal. The only application I could think of is the ability to translate OWL axioms into constraints. I don't know if one would want to go in reverse. But in any case, one of the deliverables is mapping to OWL. It would make decisions on how to map. 

-----Original Message-----
From: Peter F. Patel-Schneider [mailto:pfpschneider@gmail.com] 
Sent: Monday, January 26, 2015 3:20 PM
To: Irene Polikoff; 'Jerven Tjalling Bolleman'
Cc: 'RDF Data Shapes Working Group'
Subject: Re: shapes and classes: different

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In ShExC the mere presence of the square shape triggers recognition so here  at least there is a difference.  Similarly, the two versions of square have different consequences in OWL.

peter


On 01/26/2015 11:59 AM, Irene Polikoff wrote:
> This doesn't answer my question as to how practically these are 
> different.
> 
> In the shape validation, we are saying that the validation will occur 
> if something explicitly indicates that it should. For example, there 
> is a type triple to Square or there is another triple that says "validate"
> this resource as if it was a Square.
> 
> Given that the only information available is
> 
> ex:whatami rdf:type ex:rectangle . ex:whatami ex:width "5"^^xsd:int . 
> ex:whatami ex:breadth "5"^^xsd:integer .
> 
> ex:whatami will not be validated against the Square definition. If the 
> type triple was present (or there was some other statement that says 
> validate ex:whatami against Square), then it would be validated. How 
> the type triple gets to be there is outside the scope.
> 
> 
> -----Original Message----- From: Peter F. Patel-Schneider 
> [mailto:pfpschneider@gmail.com] Sent: Monday, January 26, 2015 2:25 PM
> To: Irene Polikoff; 'Jerven Tjalling Bolleman' Cc: 'RDF Data Shapes 
> Working Group' Subject: Re: shapes and classes: different
> 
> Consider the following RDF graph
> 
> ex:whatami rdf:type ex:rectangle . ex:whatami ex:width "5"^^xsd:int . 
> ex:whatami ex:breadth "5"^^xsd:integer .
> 
> In the former situation, ex:whatami is not a square but in the second 
> it is.
> 
> peter
> 
> 
> On 01/26/2015 11:04 AM, Irene Polikoff wrote:
>> < Saying that a square is subclass of a rectangle and that squares 
>> have their width and breadth equal doesn't make square a shape>
> 
>> <Saying that squares are precisely those rectangles whose width and 
>> breadth are equal does make square a shape>
> 
>> For practical purposes, what is the difference?
> 
>> -----Original Message----- From: Peter F. Patel-Schneider 
>> [mailto:pfpschneider@gmail.com] Sent: Monday, January 26, 2015 1:21 
>> PM
>> To: Irene Polikoff; Jerven Tjalling Bolleman Cc: RDF Data Shapes 
>> Working Group Subject: Re: shapes and classes: different
> 
>> The defining characteristic of shapes is that they are provided with 
>> conditions that determine which objects belong to them.  Saying that 
>> a  square is subclass of a rectangle and that squares have their 
>> width and breadth equal doesn't make square a shape even though it 
>> may be the case that objects belonging to square are precisely those 
>> objects that have an rdf:type link to  it. Saying that squares are 
>> precisely those rectangles whose width and breadth are equal does 
>> make square a shape as this provides a set of conditions that 
>> determine when an object is a square.
> 
>> peter
> 
> 
>> On 01/26/2015 09:24 AM, Irene Polikoff wrote:
>>>> Your word shape is my word owl:Class.
> 
>>> +1
> 
>>> So, the simplest solution is not to have a new thing called Shape.
> 
>>> Another option may be to use it as a type so that some classes can 
>>> be  of type Shape as well as Class.
> 
>>> This seems to be unnecessary though as every class is already a 
>>> shape. At minimum, even if there are no other constraints declared 
>>> for a class, it says that all instances belonging to it must have a 
>>> certain type triple. If there is a class :Person, then its instances 
>>> must have :Person1 a ::Person triple (whether it is asserted or 
>>> inferred, doesn't matter). A very minimalistic data shape, but still 
>>> a shape.
> 
>>> Irene
> 
>>> On Jan 26, 2015, at 11:12 AM, Jerven Tjalling Bolleman 
>>> <jerven.bolleman@isb-sib.ch <mailto:jerven.bolleman@isb-sib.ch>>
>>> wrote:
> 
>>>> I really can't help myself...
>>>> 
>>>> On 26/01/15 15:12, Peter F. Patel-Schneider wrote:
>>> The most important aspect of classes is that you state that objects 
>>> belong to them.  If you don't state that objects belong to X, X is 
>>> not  a class.
> 
>>> The most important aspect of shapes is that you provide conditions 
>>> stating precisely when an object belongs to them.   If you don't 
>>> provide conditions stating precisely when an object belongs to X, X 
>>> is not a shape.
> 
>>> Having shapes also be classes implies that you state that objects 
>>> belong to shapes.  Having classes also be shapes implies that you 
>>> provide recognition conditions for classes. Both situations are 
>>> possible, but both have consequences.
>>>>> Your word shape is my word owl:Class. Allowing class membership 
>>>>> inference from recognition conditions is as normal as class member 
>>>>> ship assertion directly in the data. But I am absolutely 
>>>>> flabbergasted that I am having this argument with one of the OWL2  
>>>>> editors!
>>>>> 
>>>>> Basically I am reading your response as class membership only 
>>>>> inferred is "shape membership". Class membership asserted is not  
>>>>> "shape membership". Or paraphrased: Shapes only allows triples 
>>>>> with the shape:member predicate (IMO equivalent to rdf:type) to be 
>>>>> inferred and not asserted.
>>>>> 
>>>>> 
> 
>>> peter
>>>>> 
>>>> 
>>>> --
>>>> -------------------------------------------------------------------
>>>>  Jerven Bolleman                        Jerven.Bolleman@isb-sib.ch
>>>>  <mailto:Jerven.Bolleman@isb-sib.ch> SIB Swiss Institute of 
>>>> Bioinformatics  Tel: +41 (0)22 379 58 85 CMU, rue Michel Servet 1
>>>> Fax: +41 (0)22 379 58 58 1211 Geneve 4, Switzerland www.isb-sib.ch  
>>>> <http://www.isb-sib.ch> - www.uniprot.org <http://www.uniprot.org>  
>>>> Follow us at https://twitter.com/#!/uniprot
>>>> -------------------------------------------------------------------
>>>>
>
>>>> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUxqF/AAoJECjN6+QThfjzKnMIANPI5/34quC9JVZ46WpvAa+O
7dNeL7t9toXjVXULDAHN42uJ2LwWK4BgmnWgabZFLa1FYQSyUyGxOZI65Vi3ApM8
qOgrF9EB01hRSCd6LRnJEaRAPDCRT0ljjP3qS7KSNAKiQR7cxe0K6a9F9T6TiISf
sL3KFBTOC1ll7Vh8tYhgl/DtDgZCHfdDBObMYw04dQFic3SVmYNpcdsrdxCyiCMY
3++EGckBuh0GM9J3Psc/zIUvd64uitJ8Gjdj7m6szLF9TbYOJwpwsuZZ9gSSxODw
gAHZInlzZVUAwLbwePSJFjaR1iZ7aHLd90VSY3mgE4XTslvPYSj/pDOoRfXA0qg=
=YeiT
-----END PGP SIGNATURE-----

Received on Monday, 26 January 2015 20:46:21 UTC