Agree: ResourceShape and the list. But this is not nearly enough for a link profile.

For our link profile I would suggest two sections:

1. non-GC aware: In this case we store triples on both sides (with its inverse property), according to the domains in the table
2. GC aware:  We store only one link, and the current IBM-ELM convention is that these links are always stored on the dependent side as Eran describes. Links from the others side can be queried via OSLC Query or some more general purpose index if available (e.g. LDX or MID’s gLinx, etc. ).

As I’ve argued before since the goal of the link profile is interoperability, and since IBM-ELM is still has the largest install base of OSLC providers, some level of the link profile must insure that interoperability with IBM-ELM works out-of-the-box. I have no love or loyalty more for IBM-ELM; I’m thinking pragmatically about the customer value of a  link profile specification with which does not insure interoperability with IBM-ELM.

On a related note: last week, I had an interesting conversation with a product manager from PTC/Codebeamer. He indicated intention to increase their support for OSLC. Perhaps as more tools join the party force IBM-ELM to fix the many places where it is not even OCLS 2.0 compliant (or has defects), and perhaps move in the 3.0+ world.

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

Ed,

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
3. A combination of both.

Please speak up…

Eran

Ed

Please review the link ownership text

Link ownership

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

Thanks

eran