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

Shigeaki Matsumoto commented on OSLCPROMCO-1:
---------------------------------------------

Let me give some comment based on PROMCODE seed documents and our trial.

In our trial, PROCODE resources are generated from an application form.
In fact, we used the following vocabularies based on a resource generation order.
(The order depends on the application form itself)

1. ScopeItem composedBy ScopeItem
2. Artifact measuredBy Measurement
3. Artifact producedBy ScopeItem
4. Mesures measurement Measurement
5. WorkItem produces Artifact
6. WorkItem requiredBy ScopeItem

I would like to note that just after a child resource is linked to a parent resource,
the parent resource also links to the child resource - and vice versa.

As a result, bi-directional relation is always created between two resources.
In such a case, the query still stay simple.

If bi-directional relation is requirements, query can be simple.
If not, one directional vocabulary may be selected after considering other trials.

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


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