[oslc-core] Open Core issue cleanup: 6 (old 36) Ambiguity in Resource Shape definition + consequent questions

Wed Feb 13 12:45:03 EST 2013

As discussed in today's Core meeting, this issue is open for comments
through the end of this week.  If there are no further comments it will be
resolved as proposed below.

Related:  I will start queueing up a few open V2 issues [1] to be prepared
for each Core meeting with a goal of moving them forward or closing them
out.

[1] - http://open-services.net/wiki/core/OSLC-Core-V2-Issues

Regards,
Mike

Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170

"Oslc-Core" <oslc-core-bounces at open-services.net> wrote on 02/12/2013
02:17:03 PM:

> John Arwe/Poughkeepsie/IBM at IBMUS
> Sent by: "Oslc-Core" <oslc-core-bounces at open-services.net>
>
> 02/12/2013 02:17 PM
>
> To
>
> oslc-core at open-services.net,
>
> cc
>
> Subject
>
> [oslc-core] Open Core issue cleanup: 6 (old 36) Ambiguity in
> Resource Shape definition + consequent questions
>
> OPEN #36 Ambiguity in Resource Shape definition + consequent questions
> (JohnArwe 12/30/2011)
> Response Discussed at Jan 11 meeting. Proposal sent to list and
> response led to unclear statement if resolved.
> Having reviewed this issue on the list [1], the email thread it
> spawned [2] after the meeting [3], it appears that all our energy
> was spent on Q1 from the original email [4].  It is possible we
> agreed on the resolution for Q>1 on the call, but if we did so it
> was not recorded in minutes.  So I will recap the proposed changes
> here net of all the email thread improvements, and hopefully we can
> get consensus on tomorrow's call.
> [5] Defines the Resource Shape resource definition.  It includes the
> following property definition:
>
> > oslc:describes zero-or-many True Resource Reference n/a Type or types
of
> resource described by this shape.
>
> Q1: This allows for multiple oslc:describes triples in a resource shape,
> but leaves open what the relationship is between these values and the
> (possibly multiple) rdf:type values in any given "described" resource
> instance (i.e. what condition(s) must be true in order for a given shape
> to describe a given resource instance appears to be under-specified).
> Breaking it down case by case, and stating what I *think* is the intent
> for each (looking for confirmation/disputes of this interpretation) with
> ??? in cases where [1] really leaves me guessing.  I have implementation
> folks already interpreting the ??? cases differently, BTW.
>
> [3] clarified intent: Confirmation that the list of oslc:describes
> is intended to be the union of all rdfs:Class[es] the shape supports
>
> Proposed replacement text for oslc:describes description, from Arthur in
[6]:
>
> 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.
>
>
> As noted in [8], and confirmed in [3], It says nothing limiting, so
> oslc:instanceShape is simply orthogonal.
>
>
>
>
>
> Q2-Q6, from [7] after the meeting in [3].
>
> 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/wiki/core/OSLC-Core-V2-Issues/
> [2] http://open-services.net/pipermail/oslc-core_open-services.net/
> 2012-January/thread.html#1215
> [3] http://open-services.net/bin/view/Main/OslcCoreMeetings20120111
> [4] http://open-services.net/pipermail/oslc-core_open-services.net/
> 2012-January/001204.html
> [5] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?
> sortcol=table;table=up;up=#oslc_ResourceShape_Resource
> [6] http://open-services.net/pipermail/oslc-core_open-services.net/
> 2012-January/001210.html
> [7] http://open-services.net/pipermail/oslc-core_open-services.net/
> 2012-January/001208.html
> [8] http://open-services.net/pipermail/oslc-core_open-services.net/
> 2012-January/001215.html
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20130213/c5e989a9/attachment-0003.html>