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


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

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

Subject: Re: [oslc-core] Link guidance notes

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

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

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