Re: [oslc-core] Link guidance notes

[Jim Amsden <jamsden@us.ibm.com>]

Martin,
What you outline below is exactly what
I was suggesting. R is the associative object that contains the information
about the link.


Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:      
 "Sarabura, Martin"
<msarabura@ptc.com>
To:      
 "OASIS (oslc-core@lists.oasis-open.org)"
<oslc-core@lists.oasis-open.org>
Date:      
 04/18/2015 12:50 PM
Subject:    
   [oslc-core]
Link guidance notes
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

I had another read through the document.
 
The following sentence appears twice in
section 2.1:
Well behaved clients should gracefully
handle resource types they don't expect when exercising links in resources.
 
Following on Jim's discussion at the last
meeting regarding adding rich semantics to a link that goes beyond simple
reification, what kind of approach are you considering? It seems to me
we could achieve that result by creating a resource that represents the
rich content for the link, then putting it between the source and target:
If A -> B is the link, and -> has
some rich content, then create
A -> R -> B where R is a resource
containing the rich content.
 
PTC Integrity currently uses a name and
bit flags to represent the reified content - can't even add a timestamp
to the relationship - and that works for our customers. If a customer requested
richer content I would recommend the above approach but mostly because
adding reification would be a challenge for us.
 
I'm interesting in hearing what you recommend
Jim, if not the above approach.
 
 
Martin Sarabura
R&D Fellow, PTC