[OASIS Issue Tracker] (OSLCCORE-44) oslc:instanceShape should explicitly allow multiple values

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCORE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61163#comment-61163 ] 

Martin Pain commented on OSLCCORE-44:
-------------------------------------

@Jim "The semantics of multiple instance shapes would have to be defined in the context in which the shapes apply."
@Nick "If we allowed multiple such shapes on a single instance, the meaning would have to be defined within the shape"

I don't believe so. I believe there is no difference from specifying a single instanceShape reference.

First, to start with the definiton of oslc:instanceShape from the v2 appendix: "The URI of a Resource Shape that describes the possible properties, occurrence, value types, allowed values and labels. This shape information is useful in displaying the subject resource as well as guiding clients in performing modifications."

Given RDF's "open world assumption" (i.e. just because something isn't stated doesn't mean it isn't true) then the resource shapes can only state what properties are allowed, and can't define a closed set of allowed properties (at least not the way they work right now). So if shape A says that it allows properties X, Y and Z (with some additional constraints, such as oslc:occurs), and shape B says that it allows properties T, U and V, then linking to both as instance shapes simply says that all of properties X, Y, Z, T, U and V are all allowed, with their given constraints. What if they both define the same property? If both definitions are compatible, then fine. If they're not, then the server made an error linking to both of them, as one of them can't be true for that resource given the resource's current state.

What if both shapes define the same property (that is, use the same predicate) and their constraints on that property (e.g. oslc:occurs & oslc:representation) are compatible, but their descriptions state incompatible meanings? I think this has made me realise an assumption I have about resource shapes: that *they should not be used to add semantics to a resource*. As the v2 spec says, they are "hints to clients at resource creation, update or query time". The predicates themselves should define the semantics of the properties on the resource, the shapes should just provide hints on how to use those properties at resource creation or query time, but does not change what it means to have that property on a resource.

Does anyone disagree with this? (i.e. that shapes can add semantics)

(However, I agree that there is no use case that I've raised, so I wouldn't push my proposal, but I think the question about shapes not adding additional semantics is an important one to settle.)

> oslc:instanceShape should explicitly allow multiple values
> ----------------------------------------------------------
>
>                 Key: OSLCCORE-44
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-44
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: Martin Pain
>            Assignee: James Amsden
>
> With a quick look on both Core 2.0 and the W3C member submission for Resource Shapes, it looks like neither mention whether a client can expect zero-or-one or zero-or-many instanceShape links from a resource.
> I would expect zero-or-many. As I can't see any problem with an instance having the properties from multiple shapes. This would help with the question about vendor-specific shapes raised on OSLCCORE-25 - as then the resources can include a link to both the vendor-specific shape and the OSLC TC-minted-URI for the a shape as defined in the spec.
> In v3.0 I think we should clarify this to state that a resource can specify zero or more instance shapes. (If we don't already & I missed it).



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)