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

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:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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
> 
> iQEcBAEBAgAGBQJUxQOqAAoJECjN6+QThfjzvMsH/Rk8V28jZcoBIFiJRKcL5Xf1
> uinMqRGlIkY5YTlr3/NXFm0G8osRWKXfdQaR4dlv6Q5kxAaxaTk6W6NfLBYpemJC
> QRd6y18pScv+1N7q4CsijgZTCv6iorrb0aZxBkRCPmxde3E4rdUQh7NS6skKIzjD
> j/0sO8NzuAMKloJ+w/6Q+7CiNKG10tNBgx+kkUR2MZMkvH1/57Oj22/qspUdrnKM
> K8XkB/WmMGMhnwVK4Uou8pdo7aJWlI9J92bvow6t/mRENluwv/XnGP27BfulcuuV
> 3gM5ZvvBxpMgTQNfGjD+wcBcIV/a4GzAiDL0QjipSvSzf+6aMyqCbg+5ogmWSyY=
> =BPbp
> -----END PGP SIGNATURE-----

-- 
Jerven Tjalling Bolleman
SIB | Swiss Institute of Bioinformatics
CMU - 1, rue Michel Servet - 1211 Geneva 4
t: +41 22 379 58 85 - f: +41 22 379 58 58
Jerven.Bolleman@isb-sib.ch - http://www.isb-sib.ch

Received on Monday, 26 January 2015 08:00:34 UTC