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

Arthur Ryman commented on OSLCPROMCO-1:
---------------------------------------

I reviewed the proposed new domain model. It looks much simpler.

I'd like to clarify that this Issue is about the RDF vocabulary and not the OO Domain Model. It is OK for an OO Domain model to contain links in both directions if that implies the physical design of the object instances. For example, suppose we have a scope item, scopeItem1 and a work item, workItem2. In an OO implementation we would have two objects:

scopeItem1.requires = workItem1;
workItem1.requiredBy = scopeItem2;

At the OO implementation language level, it is appropriate to have the pairs of inverse relations.

However, when we translate this to RDF we should use just one term, e.g. promcoode:requiredBy. The RDF representations are e.g.

Representation of <http://example.org/scopeItem/1> :

   <http://example.org/scopeItem/1> a promcode:ScopeItem .
   <http://example.org/workItem/2>  promcode:requiredBy <http://example.org/scopeItem/1> .

Representation of  <http://example.org/workItem/2> :

   <http://example.org/workItem/2 a promcode:WorkItem .
   <http://example.org/workItem/2 promcode:requiredBy <http://example.org/scopeItem/1> .

Each document links to the other, so you can navigate between them, i.e. if you HTTP GET scope item 1 you can navigate to work item 2, and conversely.

> 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.2.2#6258)