[oslc-core] Ambiguity in Resource Shape definition + consequent questions
Arthur Ryman
ryman at ca.ibm.com
Wed Jan 18 11:42:33 EST 2012
John,
I think both mine and yours could be simplified to just this:
This shape describes resources that are of any of these types. 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.
Regards,
___________________________________________________________________________
Arthur Ryman
DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) |
+1-416-939-5063 (mobile)
|------------>
| 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:40 AM |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [oslc-core] Ambiguity in Resource Shape definition + consequent questions |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120118/621a764a/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 17111472.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120118/621a764a/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120118/621a764a/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120118/621a764a/attachment-0002.gif>
More information about the Oslc-Core
mailing list