- From: Holger Knublauch <holger@topquadrant.com>
- Date: Tue, 27 Jan 2015 10:19:40 +1000
- To: public-data-shapes-wg@w3.org
- Message-ID: <54C6D99C.2090604@topquadrant.com>
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:
> -----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 Tuesday, 27 January 2015 00:20:14 UTC