- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 06 Feb 2015 08:30:51 +1000
- To: public-data-shapes-wg@w3.org
On 2/6/15 6:31 AM, Arthur Ryman wrote: > Holger Knublauch <holger@topquadrant.com> wrote on 01/29/2015 06:55:33 PM: > >> BTW wouldn't it have been better to use "oslc:shape" instead of >> "oslc:instanceShape", because you don't really talk about "instances" >> (of classes)? > Holger, > > Historically, we first defined oslc:resourceShape as a way to link a shape > with a service endpoint URI (essential a container) where you could create > resources via POST or query them via GET. > > However, we needed a way to support PUT operations. When a client GETs a > resource it can look in it for an oslc:instanceShape triple. That tells > the client how it can modify the resource and PUT it back to the server. > > The point is that if we just used one oslc:shape property then its meaning > would be ambiguous in the RDF description of a service endpoint. A service > endpoint description document needs to refer to its own shape as an RDF > graph AND the shape of the RDF graphs that you, e.g., POST to it. My suggestion was to simply rename :instanceShape to :shape, not to merge this property with another property. I may not have been clear, or did oslc:shape already have another meaning? > > The term "instance" was used because in many cases the RDF graph does in > fact represent some instance of an OO programming language object that > lives in the server. We picked the term so that typical web application > developers would understand it. Yep, that's the same reason why I believe sticking to general OO would have benefits. Holger
Received on Thursday, 5 February 2015 22:31:24 UTC