[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=61587#comment-61587 ] 

James Amsden commented on OSLCCORE-56:
--------------------------------------

Here's another refinement and elaboration of Martin's update above. This one describes four proposals, updates the use case to include query for backlink properties, and concludes that Martin's proposal wouldn't support these queries.

1. oslc:Property constraint has a link to its inverse property definition

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: an oslc:ResourceShape
Predicate: lqe:reversePropertyDefinition
Object: an oslc:Property resource

Use case: Provides the ability for a query of {A <AtoB> ?} assertions to include triples derived from assertions of the form {? <BtoA> A} where <AtoB> is the lqe:reversePropertyDefinition of <BtoA>.

2. rdf:Property oslc:inverseLabel <inverse label string>

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 rdf:Property oslc:inverseLabel whose comment is "Provides a human-readable label for the inverse of the subject property." An rdf:Property could have an oslc:inverseLabel to describe the property from the object to subject perspective.
ex: oslc_qm:validatesRequirement oslc:inverseLabel "validatedBy". Looks like ReSpec handles these properties.

Note that this is added to the vocabulary, not the shapes that constrain what can be asserted, and this inverse label does not introduce the possibility of any additional assertions. This approach does not support unification of link and backlink properties in a query as does proposal 1.

Subject: an rdf:Property (i.e. NOT part of resource shapes - although we could extend its use to there)
Predicate: oslc:inverseLabel
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. An oslc:Property constraint can be marked as ext:isInverseProperty: true

OSLC Core 3.0 Resource Shape suggests Extensions Vocabulary (which may be removed) suggest: 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. That is, this oslc:Property constraints specifies that there might be triples for which the applicable resource is the object of the olsc:propertyDefinition predicate. We might assume some other oslc:Property constraint has teh same oslc:propertyDefinition value for which this oslc;Property is considered the inverse.

Subject: an oslc:ResourceShape
Predicate: ext:isInverseProperty
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).

Use case: Provides the ability for a query of {A <AtoB> ?} assertions to include triples derived from assertions of the form {? <BtoA> A} where the oslc:Property constraint for A includes an oslc:Property constraint with oslc:propertyDefinition <BtoA>, and ext:isInverseProperty: true.

4. oslc:Property constraint has ext:inversePropertyName String

This is a partial combination of 1 and 2. Like proposal 1, the inverse information is in the shape, not the vocabulary. Like proposal 2, only the label of the inverse is provided, not any other metadata.

Subject: an rdf:Property (i.e. NOT part of resource shapes - although we could extend its use to there)
Predicate: ext:inversePropertyName
Object: 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 inverse information is defined in the
- vocabulary (involve RDFS rdf:Property)
- constraints (involve ResourceShapes).

B. Whether the inverse information is available in resources related to the:
- subject of the triple (inverse labels on resource shapes oslc:Property constraints),
- predicate of the triple (inverse labels on "rdf:Property"s)
- object of the triple (inverse properties).

Martin’s proposal:
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.)

Neither of these proposals provide the metadata needed to allow the report builder to include backlink properties whose values are not directly asserted on the subject (i.e., stored as assertions for which the subject is the object of an "inverse" assertion, possibly in another repository).

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.

However, (I) is impacting the vocabulary for a domain with information that does not contribute any semantics.

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