OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-promcode message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

Arthur Ryman commented on OSLCPROMCO-1:

@Fan the existence of pairs of inverse properties makes it difficult to write queries because the relation may be expressed either way. For example, suppose we are given requirement-42 and want to find all the testcases that validate it. If we have both "validates" and "isValidatedBy" then our query is like this:

{<requirement-42> :isValidatedBy ?testcase} UNION {?testcase :validates <requirement-42>}

If we simplify the vocabulary and only use :validates then the query is simplified to:

{{?testcase :validates <requirement-42>}

The triple: "<testcase-137> :validates <requirement-42>" may be in either the document for testcase-137 or the document for requirement-42. There is no need for the document URI to be the subject of the triples it contains. In fact, the same triple could be in both documents, neither document, or in some other documents.

When we define the resources in PROMCODE we can specify which triples they should contain.

> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]