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

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

If shapes cannot be the object of rdf:type triples, then they probably
should not be considered to be classes.

peter


On 01/25/2015 03:46 PM, Holger Knublauch wrote:
> On 1/26/2015 0: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 .
> 
>> Yes, you have a point there. Maybe such triples need to be made
>> illegal, e.g. by introducing a constraint on the class ldom:Shape, to
>> prevent anyone from directly instantiating an instance of ldom:Shape
>> unless the shapes are also classes.
> 
>> I believe there are many cases of "illegal triples" that would break
>> the assumptions of the meta-language. This is a bit like the
>> distinction between OWL Full and OWL DL. In OWL Full people can mess
>> around with the system vocabulary, e.g. to declare rdf:subClassOf
>> rdfs:domain owl:Nothing, which would probably make all OWL DL models
>> unsatisfiable.
> 
>> For the rdf:type case above, the alternative design is to make
>> ldom:Shape = rdfs:Class like it was in my original design. But this
>> does not seem to satisfy the ShEx supporters, and the W3C process
>> suggests that we try to find a middle ground compromise.
> 
>> Holger
> 
> 
> 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

iQEcBAEBAgAGBQJUxZavAAoJECjN6+QThfjzyjIH/1WzFGurNjb2rMC/4xWqJDDA
6vd6X9VrUe2WvNt4BE/CaZcRx8YSSDgjNAAMfI6WBkc3KcyTry8+PoHifl66ek6h
XA6A8oh5E3lH3taU/rPyfnjFHtZZnKzvvpb0n6amefBUVKiYZVBpG+fPD+25RI5M
v5bghAx2wkraUPvZQbDhJ+Ip4CZ/YiMFroB101KfmgoBpYLXcMg4F1RR1dV2CWue
J1X5D45dBmdP5ubH71PgSTDyxz3+Z/aryXPwoxlW+/v9/BJ8ZyokHxOO5jrsRQKw
NybHxYeZN8VND1CF8x2I9PBEa/C+RdshlNLB85rqZ1WERV/TixbYWMwqjWcLXH8=
=MEW9
-----END PGP SIGNATURE-----

Received on Monday, 26 January 2015 01:22:21 UTC