- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Tue, 28 Apr 2015 17:28:38 -0700
- To: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 So there are then no requirements that rely on rdf:type to directly link instances with shapes. peter On 04/28/2015 05:23 PM, Holger Knublauch wrote: > I didn't say that "link instances with shapes" must rely on rdf:type > *only*. Of course it could also be a path expression > rdf:type/sh:classShape as has been proposed elsewhere. This is certainly > a possibility, e.g. > > ex:MyClass sh:classShape [ sh:property [ ... ] ; sh:constraint [ ... ] ] > . > > but I believe the "syntactic sugar" of being able to use classes as > shapes directly will be important for the acceptance of this language: > > ex:MyClass sh:property [ ... ] ; sh:constraint [ ... ] . > > I was merely reacting to Arthur's statement that my proposal would > violate existing agreements. I don't believe it does. And I remain open > to adjusting the draft if the WG decides on a level of indirection. My > draft clearly marks this issue as unresolved. > > Holger > > > On 4/29/2015 10:11, Peter F. Patel-Schneider wrote: I do not believe that > either of these requirements relies on rdf:type to "link instances with > shapes". They do, of course, require some connection between a class and > a shape, but that is different. > > peter > > > On 04/28/2015 05:05 PM, Holger Knublauch wrote: >>>> On 4/29/2015 10:03, Peter F. Patel-Schneider wrote: I would like to >>>> see an explanation of which approved requirement relies on rdf:type >>>> to "link instances with shapes". >>>> >>>>> https://www.w3.org/2014/data-shapes/wiki/Requirements#Association_of_Cla ss_ > >>>>> with_Shape >>>>> >>>>> https://www.w3.org/2014/data-shapes/wiki/Requirements#Selection_by_type >>>>> > >>>>> HTH Holger >>>> >>>> >>>> peter >>>> >>>> On 04/28/2015 03:50 PM, Holger Knublauch wrote: >>>>>>> Hi Arthur, >>>>>>> >>>>>>> On 4/29/2015 5:00, Arthur Ryman wrote: >>>>>>>> Holger, >>>>>>>> >>>>>>>> Your proposal looks like a revival of a discussion we had >>>>>>>> months ago. >>>>>>> Yes I remember these long discussions, and I am aware some >>>>>>> people are tired of this topic. >>>>>>> >>>>>>>> Shapes and Classes are very different things. A Shape is a >>>>>>>> set of constraints on a graph. A Class has a set of member >>>>>>>> resources that define its extension. The group decided to >>>>>>>> keep these concepts separate. >>>>>>> Yes, they are conceptually different. But can you point me at >>>>>>> a "decision" by the WG that would make my proposal invalid? >>>>>>> >>>>>>>> You seem to be repeating the same arguments. What is >>>>>>>> different now? Why should the WG reverse its earlier >>>>>>>> position? >>>>>>> As discussed many times, the WG comprises of different camps. >>>>>>> Some people believe Shapes are all they need, others believe >>>>>>> that it would be foolish to ignore the existing structures >>>>>>> and previous work related to classes and replace it with a >>>>>>> parallel universe. We have approved requirements that rely on >>>>>>> rdf:type to link instances with shapes. I would appreciate if >>>>>>> both sides try to understand each other. My proposal aims at >>>>>>> making both view points possible. People who prefer to stay >>>>>>> in pure Shapes can use sh:Shape + sh:nodeShape, while others >>>>>>> can use rdf:type + rdfs:Class. Yes we could completely >>>>>>> separate sh:Shape and rdfs:Class, yet I see more downsides >>>>>>> than advantages of such a design. In particular, >>>>>>> cross-inheritance of constraints becomes messy if you have >>>>>>> rdfs:subClassOf + sh:extends. >>>>>>> >>>>>>> Instead of having philosophical discussions, I have opened >>>>>>> this thread to try to examine specific proposals, with >>>>>>> specific metamodels. If someone has better suggestions, then >>>>>>> I would like to read details about them. As this >>>>>>> Class-vs-Shapes topic is very important to some people here, >>>>>>> I believe we have best chances with a proposal that allows >>>>>>> both modeling approaches to be used, and then let the users >>>>>>> decide which design they prefer in practice. It's a web-based >>>>>>> standard after all. >>>>>>> >>>>>>> Thanks Holger >>>>>>> >>>>>>> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVQCW2AAoJECjN6+QThfjzNYoIAJ3N/et4tL8z8r3GpP48DkZs DDxawIfhHlCrtGp7DVXxyzegG74dN/QayM2r2LKKrJNHuPx5qt7ta5OP3z8/EU81 82IdToCyT4COQ/OE9iFXceIbEuXV0BAPDYuDXwKgVO25woXCNUNe3s/B2HVUugM8 dlQRhmzLmd0p+yhCKzpkfhhUDugIJS87O8303TdQpQyc/SkIY1qpKmBelflYT4Ha 92WGD5s/gwZkliESyckdYgEs/pd4ySnqOru2NrWMkqOs7Wj8czcNpE8jH+a5ocsb RoLeCoSJEPyZC5SHBvx2jUQXKUOGfXDQSmH6rVc0puW7WARikmsVY467MlhqLUc= =nNrI -----END PGP SIGNATURE-----
Received on Wednesday, 29 April 2015 00:29:08 UTC