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: [OASIS Issue Tracker] (OSLCCORE-44) oslc:instanceShape should explicitly allow multiple values


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

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

One scenario I was thinking of is where the multiple instance shapes were to be used for multiple purposes. For example, one shape might tell a client "This is the set of properties on this resource, what they mean, and what format or type they have." Another shape might tell a client "This is the set of properties you can PUT to update this resource". The two shapes might well be incompatible - there might be properties that exist that you cannot PUT, and there might be a property not currently in the resource that you must include in a PUT because it has become mandatory for new revisions or versions of that resource. It was in this context I was think oslc:usage might be a way to tell the intended use of the instance shape.

And yes, I do believe that shapes *add* semantics to vocabulary terms. A vocabulary defines the meaning of a term in the abstract, while a shape adds more context-specific meaning to a use of that term in some property of some resource For example, the Dublin Core vocabulary has the following description of dcterms:contributor: "An entity responsible for making contributions to the resource.", while the shape for a change request in the OSLC CM 2.0 spec includes text under dcterms:contributor that reads "The person(s) who are responsible for the work needed to complete the change request". If the shape could not add any more refined description of a property, we would have no need of the dcterms:description field on oslc:Property - we could simply defer to the rdfs:comment on the term itself.

What I would agree with is that shapes should not *change* semantics - that is, the use of a term in a shape should not be inconsistent with the definition of that term in its vocabulary.

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


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