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-48) Allow ResoureShapes to extend other ResourceShapes


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

Martin Pain commented on OSLCCORE-48:
-------------------------------------

I agree this is something that would be good to have, conceptually. (Not that our implementation uses resource shapes at all, so I can't say that I'd use it if we did add this).

Re: Nick's comment:
I agree this is an important use case to consider. However, I would suggest that it would be incorrect for XX_App to use oslc:describes to like the shape to either the OSLC-defined resource type (class name), or an RM_App-defined resource type. This is because oslc:describes says that this shape desribes ALL resources of that type. This might not be a problem if the property is zero-or-one or zero-or-many, but even in that case using oslc:describes in this use case suggests that all Creation Factories that can create resources of that type will accept XX_App's new property, which is unlikely to be the case.
I'd question whether in the use case as described whether Resource Shapes are the right way to make that property known. For me, Resource Shapes are best used to describe resources that are passing a certain interface (e.g. into a Creation Factory, or returned from a GET), although I do know they can be used to describe a resource in general. IN this use case, there is no interface to describe. In fact, in any case where the property lives in a different representation/graph from the one identified by its subject URI I don't believe Resource Shapes as they stand can help.

I'd hesitate to go down the "reverse property descriptions" approach, although a way to say "the representation/graph of resource with URI X will contain properties with X as the object and a resource with shape S as the subject" might be useful, but sounds like it would probably end up too complex.



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


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