Uploaded image for project: 'OASIS OSLC Lifecycle Integration Core (OSLC Core) TC'
  1. OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
  2. OSLCCORE-61

Conjunctive vs. Disjunctive semantics for multiple applicable shapes

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: None
    • Labels:
      None
    • Proposal:
      Hide

      OSLC Resource Shapes 3.0 should not address adding support for conjunctive and disjunctive composite constraints. The requirement for this should rather be addressed by W3C SHACL where there is sufficient language syntax and semantics to handle it.

      The easiest way to resolve this is to simply remove "However, the specification for a service description MAY define alternate semantics. For example, a service MAY require that the resource satisfy the constraints defined by at least one of the shapes (OR semantics)." from the second to the last paragraph in section 6.2.

      Alternative proposal: Change the second to the last paragraph in section 6.2 to read:

      "If more than one oslc:instanceShape or oslc:valueShape applies to a resource then that resource SHOULD satisfy all the constraints defined by all the shapes. If more than one oslc:resourceShape is specified for a service description, a service MAY require that the resource satisfy the constraints defined by at least one of the shapes. "

      Show
      OSLC Resource Shapes 3.0 should not address adding support for conjunctive and disjunctive composite constraints. The requirement for this should rather be addressed by W3C SHACL where there is sufficient language syntax and semantics to handle it. The easiest way to resolve this is to simply remove "However, the specification for a service description MAY define alternate semantics. For example, a service MAY require that the resource satisfy the constraints defined by at least one of the shapes (OR semantics)." from the second to the last paragraph in section 6.2. Alternative proposal: Change the second to the last paragraph in section 6.2 to read: "If more than one oslc:instanceShape or oslc:valueShape applies to a resource then that resource SHOULD satisfy all the constraints defined by all the shapes. If more than one oslc:resourceShape is specified for a service description, a service MAY require that the resource satisfy the constraints defined by at least one of the shapes. "

      Description

      The second to the last paragraph in section 6.2 says:

      "If more than one shape applies to a resource then that resource SHOULD satisfy all the constraints defined by all the shapes (AND semantics). However, the specification for a service description MAY define alternate semantics. For example, a service MAY require that the resource satisfy the constraints defined by at least one of the shapes (OR semantics). "

      This results from a different meaning of the different ways shapes are associated with resources:
      1. oslc:instanceShape - directly associates a constraining shape with a resource
      2. oslc:resourceShape - associates a constraining shpae with the entity request or response resource of a service
      3. oslc:valueShape - associates a constraining shape with the resource that is the object value of a property of a resource

      The introduction of OR semantics might be because of some confusion caused by the way oslc:resourceShape is described. In the description above, the shape is applicable to the resource produced or consumed by the service. However, the oslc:resourceShape Property section describes oslc:resourceShape as "used to link an application service description with a shape resource that describes some aspect of the service's API contract", describing the resources involved in the service, not constraining the actual resources. This perspective is implicitly OR semantics since the service might describe more than one resource.

      This could be an unfortunate coupling of the idea of applicable constraints on a resource, and descriptions of resources involved in a service. These don't seem like the same thing.

        Attachments

          Activity

            People

            • Assignee:
              jamsden James Amsden
              Reporter:
              jamsden James Amsden
            • Watchers:
              3 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved: