[oslc-core] Proposal for Core issue Creation Resources #5 (was: programmatic selection of creation factories)

Tue Jun 15 08:44:04 EDT 2010

Steve,

The oslc:resourceType property specifies information that could be 
determined by looking at the oslc:describes property of the Shape. 
However, it seems people feel that retrieving the Shape is too awkward so 
you are adding a new property. This means the set of resources can become 
inconsistent. The spec should include a requirement that the 
oslc:resourceType is the same as the oslc:describes of the Shape.

I looked at the current text for oslc:describes:
oslc:describes (Resource, exactly-one) The URI of the resource definition 
that this shape describes. 

I don't think that is very clear since it introduces the term "resource 
definition" which is not defined anywhere. A Shape is as close to a 
resource definition as we get. I suggest the following text:
oslc:describes (Resource, exactly-one) The URI of the resource type that 
this shape describes. 

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:
Steve K Speicher <sspeiche at us.ibm.com>
To:
oslc-core at open-services.net
Date:
06/14/2010 03:43 PM
Subject:
[oslc-core] Proposal for Core issue Creation Resources #5 (was: 
programmatic selection of creation factories)
Sent by:
oslc-core-bounces at open-services.net

To summarize, there are a few scenarios to be supported: 
1. Identify the type of resource that will be created.  For example, 
Requirement, Change Request, ... 
2. Identify the usage of the service.  For example, query the only returns 
Test Cases ready to be tested, Change Requests that are currently active, 
... 

To support these two scenarios, I recommend we define two new properties: 
1. oslc:resourceType  (anyURI, zero-or-many) Identifies the expected 
resource type from requests to the associated service.  This URI does not 
have to be in the namespace of OSLC. 
2. oslc:usage  (type of anyURI, zero-or-many) Identifies service usage or 
purpose for defined domain usage scenarios. 

These addition properties apply to these resource types: 
- Factory 
- QueryCapability 
- Dialogs 

Sample: 
   <oslc:service>
     <oslc:Service>
        <oslc:domain>http://example.com/xmlns/example-cm#</oslc:domain>

        <oslc:creationFactory>
           <oslc:CreationFactory>
              <dc:title>Location for creation of Blog Entries</dc:title>
              <oslc:label>Blog Entries</oslc:label>
              <oslc:creation rdf:resource="
http://example.com/creation/entries" />
              <oslc:shape rdf:resource="
http://example.com/shapes/blogentry" />
              <oslc:resourceType>
http://open-services.net/xmlns/bogus/blogs#Entry</oslc:resourceType>
              <oslc:usage>
http://open-services.net/xmlns/bogus/headlessBlogEntryCreation
</oslc:usage>
           </oslc:CreationFactory>
        </oslc:creationFactory>

     </oslc:Service>
  </oslc:service>

Note: Shape is not required for this.  If the type is a domain defined 
resource type, the client can utilized hard-coded knowledge about the 
shape. 

Some suggestions that were excluded: 
dcterms:identifer as it is "An unambiguous reference to the resource 
within a given context. ",  which this is not as it is possible to have 
multiple factories for the same resource type for instance. 
dcterms:type which is defined as "The nature or genre of the resource." 

I'm not married to the property names.  Feedback welcome on this addition. 

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

----- Forwarded by Steve K Speicher/Raleigh/IBM on 06/14/2010 12:23 PM 
----- 

Jim des Rivieres/Ottawa/IBM wrote on 05/31/2010 09:57:06 AM:

> From: Jim des Rivieres/Ottawa/IBM at IBMCA 
> To: Scott Bosworth/Raleigh/IBM at IBMUS, David M Johnson/Raleigh/
> IBM at IBMUS, Steve K Speicher/Raleigh/IBM at IBMUS 
> Cc: John Wiegand/Minneapolis/IBM at IBMUS, oslc-core at open-services.net 
> Date: 05/31/2010 09:57 AM 
> Subject: programmatic selection of creation factories 
> 
> 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