Re: ISSUE-23: A specific proposal

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