Re: Shapes are Classes, even if you don't use rdf:type

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

My view is that shapes and classes have significant differences.  This is
not to say that there are not any commonalities, but that the differences do
need to be taken into account.  Forcing inclusion one way or the other is
making a statement that has definite consequences.

Allowing information into inputs but then ignoring it seems to me to be
problematic.  I would be against such a facility.

peter


On 01/26/2015 12:00 AM, Jerven Tjalling Bolleman wrote:
> Hi Peter,
> 
> Thank you for taking the time to reply.
> 
> The main thing I wanted to bring up is that shapes are very classy in
> their behavior. The split between classes and shapes is therefore a bit
> difficult to explain and this leads to confusion. I also think in my
> opinion that introducing a hard distinction is not necessary.
> 
> Now about your specific reply. I would like to see that triples such as
> 
> ex:myOffice rdf:type :officeShape .
> 
> Are allowed in the data, but must be ignored by the shapes processor if
> it knows the shape (i.e. must re-infer), if it does not know the shape
> then it should be used as any other triple (allows shape processor
> stacking). i.e. A shapes processor may not trust user submitted data
> about class/shape membership.
> 
> In practice I would expect the user community to do the following
> 
> ex:myOffice a rdf:Class .
> 
> ex:westWingOfficeShape rdfs:subClassOf ex:myOffice . 
> ex:offsiteOfficeShape rdfs:subClassOf ex:myOffice .
> 
> The idea being that shapes reasoning will be cheap (unlike OWL) and
> encourage more specific subclasses being generated. Which I honestly
> think would be an improvement for the semweb.
> 
> Regards, Jerven
> 
> On 2015-01-25 15:54, Peter F. Patel-Schneider wrote: If shapes are
> classes then it is possible to assert that an individual belongs to a
> shape, as in
> 
> ex:myOffice rdf:type officeShape .
> 
> Because it is possible to not belong to a shape, this introduces a new
> kind of contradiction (and contradictions are indeed different from
> constraint violations).
> 
> peter
> 
> On 01/25/2015 04:25 AM, Jerven Bolleman wrote: Dear Working Group,
> 
> I have tried to keep to the sidelines in this discussion, but as a very 
> interested user of this kind of tech I feel I need to speak out.
> 
> Shapes are Classes, in all practical and theoretical terms [1]. ShEX 
> shapes are just another way to infer class membership (Closed World but 
> otherwise basically OWL all over again)
> 
> Instead of inferring example:A is a member of an owl:Class you now infer 
> that example:A is a member of things that have shape Y. Using the word 
> shape instead of Class is good to avoid confusing between OWL and this 
> standard, but they are the same thing just relabelled.
> 
> 
> The fact that shapes tries to avoid rdf:type at all cost is going to be a
> real problem in even trivial real world cases. e.g.
> 
> example:office example:telNo “+41 41 41 41” .
> 
> example:person example:name “example person” ; example:telNo “+32 32 32 
> 32” .
> 
> <officeShape> { example:telNo xsd:string }
> 
> <personShape> { example:telNo xsd:string example:name xsd:string }
> 
> Is example:office a member of the <personShape> just without a phone 
> number? Yes or No. If it is not clear in this trivial example, how can we
> [tell] end users, reason about it and build stable software?
> 
> LDOM, SPIN and OCLS all solve this by depending on the rdf:type. Its 
> simple and clear cut.
> 
> Now sometimes a direct rdf:type use is not enough or can be confusing. 
> Because, in all proposals what is lacking is associating a 
> shape/constraint with the context in which this constraint should apply. 
> Introducing a new predicate _ldom:context_ which links a resource 
> describing when the constraint could be used.
> 
> e.g. ex:Rectangle a rdfs:Class ; rdfs:subClassOf rdfs:Resource ; 
> rdfs:label "Rectangle" ; ldom:property [ a ldom:PropertyConstraint ; # 
> This type declaration is optional ldom:predicate ex:height ; 
> ldom:minCount 1 ; ldom:maxCount 1 ; ldom:valueType xsd:integer ; 
> rdfs:label "height" ; rdfs:comment "The height of the Rectangle.” ; 
> ldom:context ex:Normal_Geometry ;  # Here we say where we intent the 
> context to apply ] . ex:Normal_Geometry rfds:label “Euclidean geometry in
> 2 dimensions” .
> 
> If we give each ldom:property an explicit way to state in which context 
> they apply we can actually deal with different people using foaf:person 
> in multiple manners. e.g. the constraints on foaf:person data being 
> submitted to a restaurant reservation site is different to the 
> constraints on foaf:person data being submitted to a car rental site.
> 
> The LDOM processor can then choose to state which contexts applies to its
> users needs. The default would sensibly be all, and allow users to white
> or black lists to include or exclude contexts as they want.
> 
> This is a much cleaner solution than the shapes one. In shapes we attempt
> to separate the ontologies and their constraints to avoid constraint
> collisions, but we just hope that we don’t import them anyway. With this
> context suggestion, constraint collisions become something we can deal
> with.
> 
> The advantage of attaching a context to constraints is that you can then 
> say something like a post request with RDF data to book the rental of a 
> car requires 1 driver, 1 driver license and 1 payment method. Currently 
> in shapes and ldom, an empty message validates as well :( Plus it allows 
> users to communicate when constraints should hold and when not. e.g. 
> describing the steps in a wizard, step 1 has less constraints  on the 
> submitted data then after step 2.
> 
> 
> Secondly, I do think that ldom should be able to work from predicates as 
> well.
> 
> ex:widthIn_cm a rdf:Property ; rdfs:label “width in centimetre” ; 
> ldom:property [ ldom:valueType xsd:positiveInteger ldom:context 
> ex:realSpace ] .
> 
> Allowing this kind of construct should help the dc:terms case where 
> rdf:types are not specified.
> 
> While modelling from a predicate is not everyone’s cup of tea I find that
> it meshes nicely with the Smalltalk message based OO paradigm, in 
> comparison to the conventional ADT type OO paradigm of Java&C++. Which is
> why I believe it should have a place in this standard.
> 
> Sometimes data does not have types associated with them. In this 
> relatively rare case I humbly suggest that the user use an existing W3C 
> standard to infer a type: namely OWL. And if OWL doesn’t float their boat
> then use a SPARQL update statement. Totally typeless data is rare and
> should not be the primary use case for this WG.
> 
> e.g.
> 
> <officeShape> { example:telNo xsd:string }
> 
> is practically equivalent to
> 
> : officeShape a owl:Class ; rdfs:subClasOf [ a owl:Restriction ; 
> owl:onProperty example:telNo ; owl:minCardinality 1 . ].
> 
> In both cases some kind of reasoning has to take place to determine if 
> the following triple
> 
> example:office example:telNo “+41 41 41 41” .
> 
> means that triples about example:office meet the criteria of 
> <officeShape>.
> 
> Now get back to work and standardise something fantastic !
> 
> Sincere regards, Jerven Bolleman
> 
> [1] If it quacks like a duck and does not carry a shotgun then for all 
> practical purposes it is a duck. All though for our favourite instance 
> example Dick Cheney its “If it quacks like a duck then its a target” ;) 
> even if what quacks wears a bright fluorescent jacket and practices law.
> 
> ------------------------------------------------------------------- 
> Jerven Bolleman                        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 - www.uniprot.org Follow us at 
> https://twitter.com/#!/uniprot 
> -------------------------------------------------------------------
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUxpd8AAoJECjN6+QThfjzc2EIAL0/Rxsdqmmbegn0on9uHa7i
Fh10gvhjQSNi6a+JKbyFnVkrw0DEwAwRyxBJb4x9azjDmcrMkJkHmZd/x8gA/3mY
oE6ME0974rXBfJHRNA2YovKP3IajR7M+tE2wIfxePks4yDxwLDfc5doYwq4/S601
9Ir+blC5DSwiWwqI/K7pa0p0vcrAUgacAik2wnXrsAd0XRm+eRSeSedfctbLumZo
UgwZK1yy+29Qwusj8ENrqX4yzvIATlfsL/5u/mOIk2IrQ7cm0z538khJRYtcOZ5e
KgIcD4go8p+vBop9hBv4N5jGDaftivn503kQ4cO6lkbdCjw0l1pGCCCwvAJB1HU=
=ZiHB
-----END PGP SIGNATURE-----

Received on Monday, 26 January 2015 19:38:09 UTC