oslc-domains message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [oslc-domains] Reified relationships in RM domain
- From: "Nicholas Crossley" <nick_crossley@us.ibm.com>
- To: "Sarabura, Martin" <msarabura@ptc.com>
- Date: Tue, 20 Mar 2018 06:39:41 -0800
I should also mention that report builders
and manually constructed queries would need to be aware of the possible
existing of those reified statements, and look for them explicitly. Querying
for triples whose subject is the 'from' resource will not find the relationship
properties expressed this way - they are properties of the reified statement.
There are semantic and other problems with reification - see https://go-to-hellman.blogspot.com/2009/05/part-3-reification-considered-harmful.html
amongst several other articles. Reification cannot identify a specific
occurrence of a triple in a given graph - it uses only triples not quads
- so cannot work completely with the graph-based representation of versioned
data we use in OSLC Configuration Management.
Nick.
From:
"Sarabura, Martin"
<msarabura@ptc.com>
To:
Jim Amsden <jamsden@us.ibm.com>,
Nicholas Crossley <nick_crossley@us.ibm.com>
Cc:
"oslc-domains@lists.oasis-open.org"
<oslc-domains@lists.oasis-open.org>
Date:
03/19/2018 07:07 PM
Subject:
RE: [oslc-domains]
Reified relationships in RM domain
Sent by:
<oslc-domains@lists.oasis-open.org>
Yes let’s not throw it all out. The
relationship may have its own properties that are not downloaded from the
object. Created by could refer to the person who created the relationship,
right? Not sure how useful that one is but I know of at least one PTC attribute
that we would want to attach to the relationship. It doesn’t belong to
the object and isn’t a property of the subject itself, it’s a property
of the relationship.
So I’m in favor of retaining the concept
and documenting it, but I suppose my other concerns re v2 compatibility
are not so critical.
Regards, Martin
From: oslc-domains@lists.oasis-open.org
[mailto:oslc-domains@lists.oasis-open.org]
On Behalf Of Jim Amsden
Sent: Monday, March 19, 2018 3:02 PM
To: Nicholas Crossley <nick_crossley@us.ibm.com>
Cc: Sarabura, Martin <msarabura@ptc.com>; oslc-domains@lists.oasis-open.org
Subject: Re: [oslc-domains] Reified relationships in RM domain
Although there are likely tools that are
expecting this behavior and may not work properly without it.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From: "Nicholas
Crossley" <nick_crossley@us.ibm.com>
To: "Sarabura,
Martin" <msarabura@ptc.com>
Cc: "oslc-domains@lists.oasis-open.org"
<oslc-domains@lists.oasis-open.org>
Date: 03/19/2018
02:30 PM
Subject: Re:
[oslc-domains] Reified relationships in RM domain
Sent by: <oslc-domains@lists.oasis-open.org>
Martin,
You are right in that the canonical example was the title. That is, when
creating a link from a requirement to something else, the client could
supply reified statements that included the title of the target resource
- or the server could fill that in by default for future readers of the
requirement. This could be useful when displaying lists of links, including
in cases where the target resource was on a server not currently reachable.
However, subsequent thinking and discussion led the committee to realize
that having the title, or any other property, copied into these reified
statement could lead to security holes - the person reading the requirement
might not have read access to the target resource. The title could contain
classified names or other words, and similarly for other properties.
We came to feel that such reified statements were unnecessary duplication
of data, and should be avoided in most cases.
Nick.
From: "Sarabura,
Martin" <msarabura@ptc.com>
To: "oslc-domains@lists.oasis-open.org"
<oslc-domains@lists.oasis-open.org>
Date: 03/19/2018
09:22 AM
Subject: [oslc-domains]
Reified relationships in RM domain
Sent by: <oslc-domains@lists.oasis-open.org>
Hi all, the previous version of the RM spec http://open-services.net/bin/view/Main/RmSpecificationV2#RM_Relationship_Propertiessays
this:
RM providers MUST accept relationship properties, as described in OSLC
Core Link Guidance. The following relationship properties are defined by
this specification: …
Then the spec lists 5 properties, all with minimum cardinality 0 and therefore
optional.
An equivalent statement does not appear in the new spec though the concept
is discussed in this section https://rawgit.com/oasis-tcs/oslc-domains/master/rm/requirements-management-spec.html#labels
Since all properties listed in the old spec are optional it’s reasonable
that they are not explicitly included in the new spec. But why not include
at least some examples in the non-normative guidance?
There is one word in the v2 spec above that seems confusing to me: accept.
This suggests that there must be a method for the client to specify the
value of a property. Do we want the client to be able to specify properties
on the relationship? If so, then how would that be done? Of the examples
given, only one might make sense – the dcterms:title. All the others could
be assigned automatically by the server though it’s not clear to me how
the server could assign multiple creators if only the currently logged
in person is creating the relationship. Anyway, maybe this is just a v2
issue but I’d like to clarify if possible.
Thanks, Martin
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]