[OASIS Issue Tracker] (OSLCCORE-56) Need to decide if inverse labels are part of Property shapes

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

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

Martin Pain commented on OSLCCORE-56:
-------------------------------------

To extend Jim's summary:

The current proposals for backlink support are:

1. IBM Jazz Reporting Service uses ResourceShape Property lqe:reversePropertyDefinition to define the inverse property. The value is the URI of the backlink Property definition (not a label)
Subject of triple: an oslc:ResourceShape
Object of triple: an oslc:Property resource
Use case: uncertain, can't find the definition

2. OSLC Core 3.0 core-vocab.html references non-normative Inverse Link Labels, but this is not adequately described in the specification. core-vocab.ttl includes oslc:inverseLabel rdf:Property: "Provides a human-readable label for the inverse of the subject property." ex: oslc_qm:validatesRequirement oslc:inverseLabel "validatedBy". Looks like ReSpec handles these properties.
Subject of triple: an rdf:Property (i.e. NOT part of resource shapes - although we could extend its use to there)
Object of triple: a string
Use case: A client is displaying information on a resource, and is aware of a triple that has that resource as its object. It wants to show the relationship of the subject of that triple to the displayed resource, so needs the inverse label. (Note no resource shapes present in this use case).
Use case: A client is displaying information about a type, and is aware of an oslc:Property in a ResourceShape *for a different type* pointing to resources of the type being displayed, where that oslc:Property's oslc:propertyDefinition links to an rdf:Property that has an inverse label, and so can display the relationship that resources of the type being displayed might have to resources of that shape. 

3. OSLC Core 3.0 Resource Shape suggests Extensions Vocabulary (which may be removed) that describe two other approaches
    - Use a Property definition for the backlink property, but mark it with ext:isInverseProperty true. These properties describe incoming links for the ResourceShape that owns the Property.
Subject of triple: an oslc:ResourceShape
Object of triple: Boolean
Use case: A ResourceShape wants to document that for any resource described by the shape there must/may be a triple that has that resource as its object. Clients displaying information about that shape (or the type it describes) can then show information about "incoming" links without having to know about other shapes. (Contrast with the 2nd use case for option 2, which requires knowledge of other resource shapes).

    - Extend Property with ext:inversePropertyName String - which is sort of a combination of 1 and 2. This approach wouldn’t support as much information on the inverse property as a URI to a Property 
Subject of triple: an rdf:Property (i.e. NOT part of resource shapes - although we could extend its use to there)
Object of triple: a string
Use case: A client is displaying information on a resource, and can see from its shape that there must/may be a triple that has that resource as its object. It wants to show the relationship of the subject of that triple to the displayed resource, so needs the inverse label. (Similar to 1st use case of option 2, but involves ResourceShapes).
Use case: A client is displaying information about a type, and is aware of an oslc:Property in a ResourceShape *for a different type* pointing to resources of the type being displayed, where that oslc:Property has an ext:inversePropertyName, and so can display the relationship that resources of the type being displayed might have to resources of that shape. 


So the use cases can be split in two ways:
A. Whether they involve ResourceShapes or just "rdf:Property"s (RDFS).
B. Whether the information is available in resources related to the subject of the triple (inverse labels on resource shapes), the predicate of the triple (inverse labels on "rdf:Property"s) or the object of the triple (inverse properties).

I suggest there are two use cases potentially worth solving:
(I) Inverse labels not involving ResourceShapes (I'd suggest oslc:inverseLabel on the rdf:Property)
(II) Inverse properties on ResourceShapes (I previously suggested an alternative to ext:isInverseProperty, which I think was ext:inversePropertyDefinition, but unlike the LQE one I suggested pointing to an rdf:Property. but let's not go down that rabbit hole unless we need to.)

(If you disagree with or don't understand any of my reasoning or explanation, please say so, so we can avoid misunderstandings.)

As we've suggested that it's not worth extending ResourceShapes at this time, I suggest we don't do anything about (II) at this time, unless someone really needs it.
However, I do suggest that we keep the solution for (I) in the spec, and probably make it normative.

> Need to decide if inverse labels are part of Property shapes
> ------------------------------------------------------------
>
>                 Key: OSLCCORE-56
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-56
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: James Amsden
>            Assignee: James Amsden
>
> OSLC Core 3.0 core-vocab.html has a brief non-normative section on inverse labels that suggest inverse properties (backlinks) should not be used (as described in link guidance), and inverse labels should be used instead. Arthur's Resource Shapes 2.0 W3C submission discussed inverses, but took a different approach. Should we decide on an approach and add the oslc:inversePropertyName to oslc:Property in Resource Shapes?



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