We have an ELM development all-hands meeting starting at the same time as the OSLC OP meeting. So at the least, I will be late joining. At the worst, I may be unable to join at all. Best regards, Davi

Gray, forwarded you the meeting invite. Unlikely today’s call will happen as Jim, Ed, and I cannot attend.

A meeting has moved and now conflicts, so I cannot attend the OSLC OP meeting today.

Hi Andrii, I echo the comments of others. Your contribution over the years has been stellar and most appreciated. It’s quite understandable that you need to focus on your PhD. I regret that I’ve not b

Thu 2nd June is a UK public holiday, so I won’t be attending the OSLC OP meeting. I will look at this next week.

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

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 a oslc:inversePropertyDefinition proper

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 the

Hi Jad, Yes – see https://github.com/oslc-op/oslc-specs/issues/454 OSLC query doesn’t support the richness of a full-blown query. Its original design was never intended to, and this was to constrain t

Not possible in the current OSLC query. There is no support for querying properties that do not exist.

Most IBM Rational ELM TRS implementations have specific code to construct the RDF representation of TRS events rather than relying on Jena’s automatic conversion of Java types to literals. The underly

Hi Jad, You can find best practice here described at https://jazz.net/wiki/bin/view/LinkedData/UseUrisForEnums. If it were an enumerated value in the spec, which it is not, then values might indeed in

They are not URIs. The values are of type xsd:string. I personally think the QM spec may have got it wrong here. If the intent was for the value to be an enumeration, it should have defined them as su

Looking at oslc_qm:status in the TestResultShape shows: oslc:allowedValue "com.ibm.rqm.execution.common.state.failed" , "com.ibm.rqm.execution.common.state.inconclusive" , "com.ibm.rqm.execution.commo

I think the HTML rendered shapes should be consistent with the RDF of the shapes. I believe the former is created from the latter by Respec. Perhaps this is a Respec issue.

An olsc:Property referenced by an oslc:ResourceShape with olslc:property must be in the same RDF graph as the resource shape. This has been a requirement since OSLC core 1.0. Best regards David Get Ou