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

On 1/26/2015 0: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 .

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
>
> 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-----
>

Received on Sunday, 25 January 2015 23:50:20 UTC