[OASIS Issue Tracker] (OSLCPROMCO-1) Simplify RDF vocabulary by eliminating redundant inverse properties

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

    [ https://tools.oasis-open.org/issues/browse/OSLCPROMCO-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=37064#comment-37064 ] 

Sean Kennedy commented on OSLCPROMCO-1:
---------------------------------------

Matsumoto-san:

Many OSLC v2 specs follow the same pattern, and many implementers took the same approach, i.e. creating the "back links" so that the relationship exists in both resource documents.

The necessity of the UNION operation for queries comes from the fact that it is not guaranteed that a bi-directional relation exists. This happens for several reasons, including:

1. some implementers not triggering a back link every time a user creates a "forward link" 2. sometimes the user creating the "forward link" does not have permission to modify the Object resource to add the back link

Whatever the case, even in a closed system where bi-directional linking can be guaranteed, there is no requirement for "inverse" triples. In the example above, it is valid RDF for the same triple, e.g. "workitem-42 produces artifact-F1" to appear in both documents.

With these considerations in mind, OSLC 3 is moving towards a uni-directional vocabulary with support for defining the inverse link name to assist UI implementers [1]. I think we ought to follow this lead.

[1]: http://open-services.net/wiki/core/Vocabulary-Annotation-Vocabulary/

> Simplify RDF vocabulary by eliminating redundant inverse properties
> -------------------------------------------------------------------
>
>                 Key: OSLCPROMCO-1
>                 URL: https://tools.oasis-open.org/issues/browse/OSLCPROMCO-1
>             Project: OASIS OSLC Lifecycle Integration for Project Management of Contracted Delivery
>          Issue Type: Improvement
>            Reporter: Arthur Ryman
>
> The current design has many pairs of mutual inverse properties. This makes writing SPARQL queries awkward since you have to include both. If you only have one way to express a fact then the queries become easier to write.



--
This message was sent by Atlassian JIRA
(v6.1.1#6155)