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

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

It is possible to directly instantiate OWL restrictions, as in

ex:John in some ex:pet ex:Dog

which says that John has a pet that is a dog.


peter





On 01/26/2015 04:19 PM, Holger Knublauch wrote:
> Maybe it helps to compare "Shapes" to the (usually anonymous) class 
> definitions used by OWL in owl:equivalentClass and rdfs:subClassOf.
> Basically, shapes describe hypothetical classes (sets of nodes) that are
> never directly instantiated.
> 
> OWL still calls those things classes, and LDOM does the same, for
> simplicity and consistency. I believe I could support the notion of
> Shapes in the context of similar use cases, in nested "class expressions"
> (ldom:all/ldom:some). If you look at Example 11 at 
> https://w3c.github.io/data-shapes/data-shapes-primer/#template-constraints
> the blank nodes of ldom:shape1 and ldom:shape2 could have a type triple:
> 
> ex:RectangleWithArea a rdfs:Class ; rdfs:subClassOf ex:Rectangle ; 
> ldom:constraint [ a ldom:OrConstraint ; ldom:shape1 [ *
> a ldom:Shape ;** *                        ldom:property [ ldom:predicate
> ex:width ; ldom:minCount 1 ; ] ; ldom:property [ ldom:predicate ex:height
> ; ldom:minCount 1 ; ] ] ; ldom:shape2 [ *                        a
> ldom:Shape ;** *                        ldom:property [ ldom:predicate
> ex:area ; ldom:minCount 1 ; ] ] ] ; .
> 
> with no harm done. But even that rdf:type triple should be optional IMHO,
> to make code more compact to edit.
> 
> Holger
> 
> 
> On 1/27/2015 5:37, Peter F. Patel-Schneider wrote: 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

iQEcBAEBAgAGBQJUxv0mAAoJECjN6+QThfjzEOQH/jVlxSDlvou7MBMVhvN4YSTs
UX7Hxkr+zsAARuPJN7v2+cM4YF10tZEIzmuWS7E4J6qyHaumxVxkrexnKZzqr49Z
BXTNEqXlrp0aYb/Z4p/Y45Mr3tLiBQ6lReSSFcdfI1py/FVJ4mdnOXviCshodno6
CBWGbQlaED+2/PpCw41hQI7aIzBw7wq0uzlcaks+h4GJBSq4bCWQo60m4HS5ooMK
keJuID/DcKofP/W3KkdRjLujHy4kuR+h+j+KjgURf9Z+VLv8e0UMVmWpE/PIcA4l
/mVTypyTk/LPrrvkwqp5zQmK6C7VfifDHxLL1OHbTl/7CiBhD1Bx/K0sj/YHjpc=
=zxVR
-----END PGP SIGNATURE-----

Received on Tuesday, 27 January 2015 02:51:49 UTC