[OASIS Issue Tracker] (OSLCCORE-48) Allow ResoureShapes to extend other ResourceShapes

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

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

Nick Crossley commented on OSLCCORE-48:
---------------------------------------

Allowing some way to extend a resource shape provides another benefit: it can have the effect of injecting a property unknown to the author of the original shape. For example, suppose you have a requirement, conforming to the OSLC RM specification and its resource shapes. The shape for this resource comes from the tool publishing that resource; let us name that RM_App. Now, another application XX_App decides to publish a triple whose subject is that requirement, but the predicate and object are something new, defined by  XX_App. We presume XX_App cannot modify the shape produced by RM_App. How can that triple get known? If the object of this triple was a resource owned by XX_App then one approach would be to extend shapes to allow reverse property definitions, and to add a reverse property for the triple being added to the requirement. However, this would not work if the object of the triple was a literal. Another, more general, approach is to allow XX_App to publish a shape that extends the shape defined by RM_App. If necessary, XX_App could also add a new rdf:type triple to the requirement from RM_App, so the requirement is covered by the oslc:describes property of the shape from XX_App. 

> Allow ResoureShapes to extend other ResourceShapes
> --------------------------------------------------
>
>                 Key: OSLCCORE-48
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-48
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: James Amsden
>            Assignee: James Amsden
>
> Many of the existing OSLC domain vocabularies are fairly simple, defining a relatively small number of RDFS classes, and rarely (if ever) use subClassOf. As a result an instance of a domain class can have an oslc:instanceShape that references a simple ResourceShape.
> However, some vocabularies, such as those derived from UML, SysML, PLE, etc. may have much richer vocabularies that have deep inheritance hierarchies. Although it is possible to create A ResourceShape for each subclass, this would result in a very large number of repeated properties as the properties inherited from superclasses would need to be copied down into the ResourceShape for each subclass in order to fully specify the resource shape. 
> I is therefore desirable to have some means of "inheriting" constraints from some other ResourceShape(s), or extend a ResourceShape with constraints defined in some other shape - a chain of constraints like prototypes in JavaScript.



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