[oslc-core] programmatic selection of creation factories

[Ian Green1]

Hello Arthur,

I don't think the current shape resource can serve to identify the factory 
in all cases.

I can see two issues:

(1) The URI of the shape resource is not canonical since different servers 
of the _exactly the same_ shape will have different shape URIs (they have 
different authorities, for example).  Core has not defined a notion of 
equality of shape resources.  Perhaps equality would work but it seems 
awkward. An identifying URI would be direct.

(2) Blog Entry resources (and therefore their shape resources) can vary 
across providers (for example, to accommodate vendor-specific extensions 
to those blog entry resources), yet a consumer needs to be able to 
identify the "create blog entry" factory, irrespective of these 
variations.  Supporting this use case needs something other than shape 
resource equality.

The ShapeResource specification does not describe the rdf:type of the OSLC 
Resource it creates;  The spec. suggests that only one resource type is so 
described:  "A Resource Shape is an resource that defines the allowed or 
required properties of one type of resource." Were this type URI to be 
part of the ResourceShape specification, programmatic clients would be 
able to select the appropriate factory. 

That said, I vaguely recall an early discussion in which decoupling of 
resource type from resource shape was seen as desirable.

best wishes,
    -ian


oslc-core-bounces at open-services.net wrote on 31/05/2010 15:21:50:

> [image removed] 
> 
> Re: [oslc-core] programmatic selection of creation factories
> 
> Arthur Ryman 
> 
> to:
> 
> Jim des Rivieres
> 
> 31/05/2010 15:22
> 
> Sent by:
> 
> oslc-core-bounces at open-services.net
> 
> Cc:
> 
> oslc-core, David M Johnson, John Wiegand, oslc-core-bounces
> 
> Jim,
> 
> A creation factory has a link to a shape (oslc:shape) resource that 
> descibes that resources it creates, e.g. blog entry versus blog comment. 

> Isn't that enough to identify the purpose of the creation factory?
> 
> 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:
> Jim des Rivieres/Ottawa/IBM at IBMCA
> To:
> Scott Bosworth <bosworth at us.ibm.com>, David M Johnson 
> <dmjohnso at us.ibm.com>, Steve K Speicher <sspeiche at us.ibm.com>
> Cc:
> oslc-core at open-services.net, John Wiegand <John_Wiegand at us.ibm.com>
> Date:
> 05/31/2010 09:57 AM
> Subject:
> [oslc-core] programmatic selection of creation factories
> Sent by:
> oslc-core-bounces at open-services.net
> 
> 
> 
> ref: http://open-services.net/bin/view/Main/OSLCCoreSpecDRAFT (r95, May 
> 27) 
> 
> Architecturally, it makes sense for a particular Service to have 
multiple 
> occurrences of creationFactory. Take the example OSLC Blog Service as a 
> concrete instance: Blog Entry and Blog Comment each have a 
> creationFactory. The CreationFactory inline local resource carries a 
> mandatory dc:title that helps a user in choosing among them. However, I 
> don't see anything that would allow a programmatic client to make an 
> analogous choice. For instance, if my client needs to create a Blog 
Entry, 
> 
> how would it discover which creationFactory to use? 
> 
> In general, OSLC domains must support the needs of programmatic clients 
as 
> 
> well as ui clients. Adding a mandatory identifier to CreationFactory 
would 
> 
> do the trick. The identifier could be a URI. Well-known URIs could be 
> defined in the OSLC domain spec; i.e., OSLC Blog Service could declare 
the 
> 
> identifiers "http://open-services.net/bogus/blog/createEntry" and "
> http://open-services.net/bogus/blog/createComment" for distinguishing 
its 
> primary creation factories. All clients would be told to tolerate and 
> ignore entries with identifiers that they do not recognize; this allows 
> new identifiers can be introduced at any time without affecting 
> programmatic clients. And the mechanism can be opened up to individual 
> providers by allowing a provider to define additional provider-specific 
> identifiers.
> 
> I would make the exact same argument for queryCapability, 
selectionDialog, 
> 
> and creationDialog as for creationFactory. Any OSLC domain that has 
> multiple major resource types might decide to provide separate query 
> capabilities, pickers, and creation uis for each type. Adding an 
> identifier to QueryCapability and Dialog would address the needs of 
> programmatic clients.
> 
> Regards, 
> Jim 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> 
> 
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU