OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Replying off of JIRA as it's a tangent from the topic of that ticket. (Also, this is just a train of thought, I don't make a point at the end...)
 
> a property definition may have multiple values for oslc:range (which is presumably intended to indicate a
> union of possible types, though it doesn't say so), and it may have multiple oslc:valueType values (the
> semantics of which are again undefined), but it may have only a single valueShape! Logically, multiple
> valueShapes should be allowed, though it would be impossible to correlate the value shapes with the value
> types and oslc:range values other than by assumptions based on the rdf:type of the linked resources.
 
I don't think there's a problem with matching value shapes up with value-types, as if it the value-type is "Resource", "LocalResource" or "AnyResource" then I expect that the single (or all) valueShapes apply, whereas if it's a non-resource value type (a literal type) then the shape doesn't apply.
 
If a property has multiple oslc:range values and a single valueShape, then I'd interpret that to mean that whichever of the types (as specified by oslc:range) are used, the shape must still apply.
 
If multiple valueShapes were allowed, then it seems to me that the simplest way to link shapes to their type as specificed by oslc:range is either to compare the types with the oslc:describes property of the shape (although that is only valid if the shape describes all instances of that type), or (for other cases) to include a Property for rdf:type in the shape, with a single oslc:allowedValue of that type. (However, the definition of resource shapes appears to be ambiguous as to whether these are exemplar values, or whether any value not specified is disallowed - I expect the latter was the intention, but this requires a "closed world assumption" - not that I expect such an assumption would be a problem in practice).
 
What's my point? Nothing, I think. Just sharing my train of thought on this in case it highlights anything that could benefit from clarification.
 
Martin Pain
 
----- Original message -----
From: OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>
Sent by: <oslc-core@lists.oasis-open.org>
To: oslc-core@lists.oasis-open.org
Cc:
Subject: [oslc-core] [OASIS Issue Tracker] (OSLCCORE-44) oslc:instanceShape should explicitly allow multiple values
Date: Tue, Oct 27, 2015 5:36 PM
 
    [ https://issues.oasis-open.org/browse/OSLCCORE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61156#comment-61156 ]

Nick Crossley commented on OSLCCORE-44:
---------------------------------------

It is not clear to me what the semantics of multiple instance shapes would be. There have been other proposals for saying that one shape extends another, via a new property on a shape, and there has been other work on dynamic merging of shapes for query builders. I do not believe we are ready to introduce multiple instance shapes as another way to address variant shapes.

As for the asymmetry in the cardinalities of resource shapes on creation factories vs. query capabilities, this was in fact deliberate. Multiple create shapes are allowed, to handle multiple possible resource types being POSTable to the same factory. On the other hand, a single query capability shape defines the shape of the single query base resource itself, which might in turn have references to resources of various types, using the valueShape property for property definitions in the outer shape. However, I do note an issue there - a property definition may have multiple values for oslc:range (which is presumably intended to indicate a union of possible types, though it doesn't say so), and it may have multiple oslc:valueType values (the semantics of which are again undefined), but it may have only a single valueShape! Logically, multiple valueShapes should be allowed, though it would be impossible to correlate the value shapes with the value types and oslc:range values other than by assumptions based on the rdf:type of the linked resources.

> 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)

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

 
 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]