[oslc-core] Ambiguity in Resource Shape definition + consequent questions

Steve K Speicher sspeiche at us.ibm.com
Tue Jan 17 16:58:17 EST 2012


John,

+1

I don't have any suggested improvements to this, I think what Arthur has 
is good and what you proposed improves it.

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


oslc-core-bounces at open-services.net wrote on 01/17/2012 09:40:27 AM:

> From: John Arwe/Poughkeepsie/IBM at IBMUS
> To: Arthur Ryman <ryman at ca.ibm.com>, 
> Cc: oslc-core at open-services.net
> Date: 01/17/2012 09:41 AM
> Subject: Re: [oslc-core] Ambiguity in Resource Shape definition + 
consequentquestions
> Sent by: oslc-core-bounces at open-services.net
> 
> > I [Arthur] suggest this description: 
> > 
> > This shape describes resources that are of any of these types. That 
is, 
> > the shape applies to resources that are in the union of the types. 
Note 
> > that if a resource has multiple rdf:type properties then the resource 
is 
> > in the intersection of those types. Therefore a shape S applies to a 
> > resource R if R has a type T and there is a triple S oslc:describes T.
> 
> Pretty good.  I'm going to counter with some tweaks that I hope reduce 
> ambiguity in the natural language portion; the final sentence's more 
formal 
> version is great, and I'll tweak that to make it a bit more formal.  The 

> union/intersection change is one to pay special attention to I suspect - 
"
> resources that are in the union of the types" throws me for a loop. 
> > This shape describes resources that are of any of these types. That 
is, 
> > the shape applies to resources whose type(s) intersect with the 
shape's 
> described type(s). 
> > Formally, a shape S applies to a 
> > resource R if there is a triple R rdf:type T and there is a triple S 
> oslc:describes T.
> 
> Since we agreed during the WG call that it is intentional and valid to 
have 
> zero oslc:describes triples in a shape (so the shape describes only 
> resources that explicitly link to it via a oslc:instanceShape  triple), 
here
> is a new (full replacement) proposal for the consequent editorial 
changes to [1]: 
> 
> Q2: (editorial change) 
> A Resource Shape describes the properties that are allowed or required 
by...
> from: one         type               of resource . 
> to:   one or more types or instances of resources. 
> I'm not entirely happy with that (seems a bit awkward still), 
> but I think it's accurate now so I claim 80-20 reached 
> and give license to the editor(s) to improve it.
> 
> Q3: answered - 0 intentional, no change 
> 
> Q4: Another disagreement between the words and oslc:describes 
cardinality 
> providing a machine-readable definition...
> from: of an          OSLC resource type              . 
> to:   of one or more OSLC resource types or instances. 
> FWIW: I kept "resource type" there, but "resource definition" might be 
> more in keeping with the rest of the specs' content... did not do a wide 

> search. 
> 
> Q5: (editorial nit) 
> OSLC Creation Factory MAY provide ...
> from: a Resource Shape  ... create a resource 
> to:     Resource Shapes ... create   resources 
> ...and a similar change for Query Capability in the next sentence. 
> 
> Q6: (editorial nit) 
> from: A Resource Shape resource can have a title and a        type . 
> to:   A Resource Shape resource can have a title and a set of types. 
> 
> 
> [1] 
> http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?
> sortcol=table;table=up;up=#oslc_ResourceShape_Resource 

> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net





More information about the Oslc-Core mailing list