[oslc-core] How will Resource Shapes be provided?

[Arthur Ryman]

Scott,

Web architecture states that you should be able to dereference a URI and 
get information about it. OSLC should therefore host information about any 
namespace we define. I doubt that this would cause a server problem 
because these documents would be fairly static and could therefore be 
cached. If the load did get high then we could redirect to a bigger 
server.

Regards, 
___________________________________________________________________________ 

Arthur Ryman, PhD, DE


Chief Architect, Project and Portfolio Management

IBM Software, Rational

Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
Twitter | Facebook | YouTube







From:
Scott Bosworth <bosworth at us.ibm.com>
To:
oslc-core <oslc-core at open-services.net>
Date:
06/17/2010 09:28 AM
Subject:
Re: [oslc-core] How will Resource Shapes be provided?
Sent by:
oslc-core-bounces at open-services.net



Nick's point is a good one - in practice, most resources will have 
provider extensions. That said, it would be valuable to providers to have 
a documented shape that is a starting point for each OSLC-defined 
resource. Perhaps each domain spec include a shape for the resources it 
defines, and possibly multiple shapes - e.g. one for creation or one for 
query? This would be a big help for services providers.

Dave, not sure if you were recommending that we put "live" shape resources 
at specific open-services.net uris? This is an interesting idea, though 
I'm not sure we understand the QoS needs and whether the open-services.net 
infrastructure could adequately support the performance characteristics 
needed. Unless we really want to push on this question, I'd suggest we 
document the domain resource shapes in the wiki.


> Nick Crossley 
> 
> 
> Presumably I misunderstood, because I always thought the provider-
> specific properties would be described in the shape - that is, your 
> choice 2(b).  I do not consider this a new feature added during 
> convergence, since we have always said that providers can add extra 
> properties, and we have said that resource shapes are there (amongst
> other things) to help during query - so surely providers should put 
> their added properties into the shape.  I fully agree such 
> properties must use a different name space. 
> 
> For this reason, I do not see a good argument for putting resource 
> shapes on open-services.net, since such shapes would not be the ones
> linked from any real resources. 
> 
> Nick. 
> 
> 
> 
> From:        Dave <snoopdave at gmail.com> 
> 
> We expect that OSLC domain specifications will specify Resource Shapes
> for some resources. How will we provide these shapes and can providers
> extend them? Consider these two question:
> 
> 1) Should we make OSLC defined shapes available at open-services.net
> or do we expect that providers will each provide these shapes as part
> of their implementation? My opinion: we should do both. Make shapes
> available on open-services.net and recommend that allow providers to
> provide them as well.
> 
> 2) If we allow implementations to provide the specified shapes, what
> are the requirements? What changes are implementations allowed to
> make? Can they add new "custom" properties? I have two opinions on
> this one:
> a) Implementation must provide the OSLC Defined Resource shapes
> verbatim with no changes and no additional properties. Resource Shape
> Extensibility is a new feature not in the spec and we shouldn't add
> new features during convergence.
> b) Implementations must not remove or add any properties to an OSLC
> defined resource shape, but may add new custom properties. To prevent
> conflicts, for custom properties, implementations should define
> entirely new properties in an entirely implementation-specific
> namespace.
> 
> Thanks,
> - Dave
> 


Scott Bosworth | IBM Rational CTO Team | bosworth at us.ibm.com | 
919.486.2197(w) | 919.244.3387(m) | 919.254.5271(f)
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net