RE: shapes and classes: different

One more thing

< Whether this sort of processing is over-zealous is not something that the working group has addressed at least as far as I know.>

I believe this can/should be derived from or, at least be connected with, the user stories and use cases. 

For example, if there is a post request with some information about let's say a new Vendor organization and there are all sort of other shapes "present" (I don't know what present means exactly, so I assume that they are just there somehow and there is nothing that said "validate against this shape only"), I'd say there is little sense in validating it against other shapes such as Purchase or Invoice or ProductReturnRequest or whatever. 

The application would expect back a message saying that the validation passed or failed and, if failed, here are the reasons. It would be highly unusual to send back a report saying that it is valid for a Vendor and not valid for 10 other things and here is why for each. At least, I never came across a design like this. 

Irene

-----Original Message-----
From: Peter F. Patel-Schneider [mailto:pfpschneider@gmail.com] 
Sent: Monday, January 26, 2015 4:32 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



On 01/26/2015 12:45 PM, Irene Polikoff wrote:
> < 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?
> 
That is how ShExC processors work, at least as far as I can tell.
Validating a shape globally does not need to be a resource-intensive process, at least in many cases.  If a ShExC shape contains a property-value pair that must be present for the shape to succeed, then a ShExC processor can use standard indexing techniques, present in triple store systems, to reduce the amount of computation required.

Whether this sort of processing is over-zealous is not something that the working group has addressed at least as far as I know.

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

I'm not aware that this is settled yet.  In any case, global triggers require investigating the entire graph, at least in principle. It appears to me that ShExC shape documents will only have a small number of shapes, so the effort to determine the extent of all shapes in a ShExC document may be similar to the effort of evaluating global triggers.

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

I suppose that this particular difference does not matter for the new standard.  However, I was unaware that you were asking for observable differences that might be related to the new standard.

The difference will also show up in OWL constraints, and presumably also in Stardog ICV.  Hopefully this appearance of the difference is standard-related.

peter

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

iQEcBAEBAgAGBQJUxrJRAAoJECjN6+QThfjz06UH/21veY7Q73lVIG+0zm9n3nn5
goUKaoRLBCsLVK3ripEnoJBwFm8jYeK6V47de9AhebzbzMuT+vEtI05H4C+EYlzs
8mOwglD9aNtonmlxdg0pbknoiE4trBmq2H2qvwc+9EDHryYvnRq0GBS1aKLk7W9h
kOXdyCqiqixr+ISCN1WNAn89ZA6N0r64yRuqUyt5ZPbHy+v5VdM/pFT6seF+xKw/
V6wgkaSNzgXVQJkUEj/rEsH3pqZl8hHYrhbpRGcBhr3RmU1xbedjS3SBjxkDi+2X
A2CSMmdy8ohOEMy7DAvzSqATvc4MN5cMrju2JXbY39P27woxqe0eH9FrcWpNQuA=
=HCp1
-----END PGP SIGNATURE-----

Received on Tuesday, 27 January 2015 00:25:12 UTC