Ian, The Shape resource contains the oslc:describes property which refers to the rdf:type of the resource. An implementation could add properties to the Shape but still refer via oslc:describes to the same rdf:type.
See [1]: oslc:describes (Resource, exactly-one) The URI of the resource definition that this shape describes. The above definition could be made clearer, but the example does illustrate the intention, i.e. it points the to rdf:type of the resource. [1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixADRAFT?sortcol=table;up=#oslc_ResourceShape_Resource 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: Ian Green1 <[email protected]> To: Arthur Ryman/Toronto/IBM@IBMCA Cc: [email protected] Date: 06/01/2010 04:14 AM Subject: Re: [oslc-core] programmatic selection of creation factories 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 [email protected] 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: > > [email protected] > > 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@IBMCA > To: > Scott Bosworth <[email protected]>, David M Johnson > <[email protected]>, Steve K Speicher <[email protected]> > Cc: > [email protected], John Wiegand <[email protected]> > Date: > 05/31/2010 09:57 AM > Subject: > [oslc-core] programmatic selection of creation factories > Sent by: > [email protected] > > > > 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 > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > > > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > 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
