David Can you please look up the link storage/discovery tables I sent and confirm? These tables are a practical basis to discuss the linking profile. Would be great if you can do before

Participants in the OSLC Open Project, The ballot to approve OSLC Configuration Management Version 1.0 PSD01 as a Project Specification, found in

Your name:

Hi, I will attend an off-site project meeting on Thursday and won’t be able to join the OP call. Please make sure to have someone take minutes. /Andrew

Well IBM/ELM/Jazz has a discovery namespace: http://jazz.net/xmlns/prod/jazz/discovery/1.0/ This was developed after 3.x because it of perceived architectural limitations of the rootservices. But

Could someone refresh my memory on what xmlns:oslc_disc=“http://open-services.net/xmlns/discovery/1.0/” is and when was it deprecated, please? /A Begin forwarded message: From:OSLC forum

Sorry I should have been more careful with my vocabulary. I meant reify in generic sense not in an RDF sense. I meant to formalize what we mean by and expect from links – and indeed we already

Hi Eran, Yes OSLC query for opt out makes sense, and it’s straight forward. we should discuss.

A few ideas and observations and a concrete proposal: A helpful idea was proposed by our French Sodius Colleague whose name escapes me. He suggested in a conversation after our last call – and

I do have one concern about Jim’s inverse link suggestion (though I generally think it’s a good idea). Implementing inverse links is more significant implementation work for IBM ELM. All

Re:We should reify the concept of link beyond just a single predicate OSLC avoids and discourages the use ofreification. It can make querying problematic, especially for OSLC query. I don’t think

As you suggest Jim, we could add a new property of an oslc:Property to indicate the reverse predicate for a link. This is not without its problems. Say we added aoslc:inversePropertyDefinition

Ed, Thanks for coming back to version 0…. Indeed this is what we should focus on and we rather call it version 1. As I mentioned in my other note, IMO for Opt-out we shouldnot recommend link

Hi David, all, Again, pulling back towards the pragmatic principle “let’s define a profile that at least guarantees ELM (jazz) cross linking”. Let’s push to the background for now

Sorry I’ve missed the discussion today. It’s a holiday here. One thing for me is very clear. If by link we mean a single predicate then we always know where it is stored. Always. It is stored

OASIS Members and other interested parties, OASIS is pleased to announce the publication of five new Project Notes from the members of the OASIS Open Services for Lifecycle Collaboration (OSLC) OP

I am specifically not proposing to store backlinks. What I’m suggesting is that which link is the forward link depends on the use case the servers are trying to support. So rather I’m proposing

I'm always for only storing the forward link. It has a clear advantage in the ability to better manage the configurations and the composition of configurations. If I could get rid of backlinks I

Always trying to create both forward and back links seems like the wrong thing to do, even in opt-out mode. Servers are free to either silently ignore RDF properties it doesn’t support, or to fail

Indeed I agree that this is a good start to the discussion. But as Jim identifies here we have some variability in the definition of where the link storage and inverse are stored. If we go on the