Re: shapes and classes: different

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

This depends on the workings of the control flow and API that the group
decides on.   As ShExC processors work by determining the extent of all
shapes, I don't see that this processing can be ruled out a priori, and the
 working group has not determined what sort of  processing is going to be
required.  I can't immediately come up with any user stories that require
this sort of processing, so maybe the final design won't include the kind of
processing that is native to ShExC processors.

peter


On 01/26/2015 04:24 PM, Irene Polikoff wrote:
> 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
> 
> 
> 
> 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

iQEcBAEBAgAGBQJUxv6BAAoJECjN6+QThfjzia8H/392Tfgcwi++FUwO3Dug0LKd
r+qS7to2v7x9T1rDYfHASRdGiexM5xWdOePXJFjWeoirAAMTNUdQ9zBjsUwQqaFU
c2ftP+6n047E2tx+MBHwoI4th9kKiejIISHULJdBMsIht7EmD96N5XGXPFrcBzU2
CvCipK9YgCdpAdiqdrq5y5NfLY++EGRxyMcScg6xfCZg7Z7XN65a2LCfmB70Nx1b
k8fjEv4Ql+zd1lVvZAnsz80aOAN5iNSRhRgWOLyV8x7hJE9V5IS3cdZrxt7Oy1zX
gjB+Yw3v3M9c+238CQ3rSVCwpLE19kykjYAjFfjYZOAXsOwlps0JyXmfBlD71DA=
=Zexk
-----END PGP SIGNATURE-----

Received on Tuesday, 27 January 2015 02:57:35 UTC