oslc-op Weekly Contributors Meeting When: 02/24/2022 10:00am to 11:00am (UTC-05:00) America/New York Where: https://meet.jit.si/oslc-op Organizer: Jim Amsden jamsden@... View

Please remember that RDF has priority over normative text and such a change will require an explanation and an errata. –Andrew

IBM has successfully implemented the OASIS Architecture Management Specification, Version 3.0, Project Specification revision 01

I see. Thanks for the link It seems easiest to correct the ttl file to start with. ______________________________ Jad El-khoury,PhD KTH Royal Institute of Technology School of Industrial

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

Hi David I understood from you that enumeration values should have URIs, instead ofxsd:string. And “com.ibm.rqm.execution.common.state.failed", for example, does classify as a valid URI. or do

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

I did react to the “ibm” in the naming as well. But besides that, what would make the values more correct then? What makes them acceptable URIs, assuming we change the valueType to be so? Would

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

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.

Hi I was looking for examples of AllowedValues, and noticed that these values are not directly visible in the HTML version of the specs, yet they are well defined in the RDF version. For

“must be in the same RDF graph" This can also mean that it is inlined in the same RDF document. Or, does it mean that it must ONLY (local) in that document? ______________________________ Jad

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

Hi I surveyed several of the shapes RDF data of our OSLC specs, and it seems that all property constraints are defined as local nodes. All are defined within their containing resource

Dear OP members, I am happy to submit the following Statement of Use, as seen in the forwarded letter approved by Martin Törngren, our KTH representative at OASIS. In particular, KTH has contributed

The OSLC Open Project Architecture Management 3.0 Specification, revision 01 has reached Candidate OASIS Standard. This revision incorporates the insight gained from many implementations, integrations

The OSLC Open Project Architecture Management 3.0 Specification, revision 01 has reached Candidate OASIS Standard. This revision incorporates the insight gained from many implementations, integrations

oslc-op Weekly Contributors Meeting When: 02/17/2022 10:00am to 11:00am (UTC-05:00) America/New York Where: https://meet.jit.si/oslc-op Organizer: Jim Amsden jamsden@... View

In Lyo, yes. But not the specs. For some.time now, We regenerated the domains in Lyo to be more inline with the specs. We can still change back in Lyo if this extension does make sense. Jad

Agree. I can’t see how one could have specified subclassing, given that it is not supported. We have had a discussion about the subclassing support in Lyo, and how it contradicts the OSLC