Date   

Errata in OSLC Quality Management Specification Version 2.1 OASIS Standard 19 January 2022

Jim Amsden
 

Chet,

We discovered a copy/paste mistake in one of the above specification’s additional components files. File quality-management-shapes.ttl contains:

 

:TestResultShape

        a                    oslc:ResourceShape ;

        oslc:describes       oslc_qm:TestResult ;

        oslc:property        [ a                        oslc:Property ;

                               oslc:allowedValue        "com.ibm.rqm.execution.common.state.failed" , "com.ibm.rqm.execution.common.state.inconclusive" , "com.ibm.rqm.execution.common.state.passed" , "com.ibm.rqm.execution.common.state.deferred" , "com.ibm.rqm.execution.common.state.incomplete" , "com.ibm.rqm.execution.common.state.blocked" , "com.ibm.rqm.execution.common.state.part_blocked" , "com.ibm.rqm.execution.common.state.perm_failed" , "com.ibm.rqm.execution.common.state.error" ;

                               oslc:hidden              false ;

                               oslc:isMemberProperty    false ;

                               oslc:name                "status" ;

                               oslc:occurs              oslc:Zero-or-one ;

                               oslc:propertyDefinition  oslc_qm:status ;

                               oslc:readOnly            false ;

                               oslc:valueType           xsd:string ;

                               dcterms:description      "Used to indicate the state of the Test Result based on values defined by the service provider. Most often a read-only property." ;

                               dcterms:title            "Status" , "Status"@en

                             ] ;

 

Ths should be:

 

:TestResultShape

        a                    oslc:ResourceShape ;

        oslc:describes       oslc_qm:TestResult ;

        oslc:property        [ a                        oslc:Property ;

                               oslc:hidden              false ;

                               oslc:isMemberProperty    false ;

                               oslc:name                "status" ;

                               oslc:occurs              oslc:Zero-or-one ;

                               oslc:propertyDefinition  oslc_qm:status ;

                               oslc:readOnly            false ;

                               oslc:valueType           xsd:string ;

                               dcterms:description      "Used to indicate the state of the Test Result based on values defined by the service provider. Most often a read-only property." ;

                              dcterms:title            "Status" , "Status"@en

                             ] ;

 

The oslc:allowedValues contained content copied from the IBM implementation that should have been removed. This was editing oversight that does not result in any changes to any of the other published specification parts.

 

Note that the Turtle file, quality-management-shapes.ttl is the normative content which the normative sections in the specification generated from this file. The oslc:allowedValues is not included in any of these ReSpec rendered documents.

 

How should we go about following an errata process to update quality-management-shapes.ttl and remove the oslc:allowedValues?

 

 


SodiusWillert Statement Of Use - OASIS Architecture Management Specification 3.0

François-Régis Jaunatre <frjaunatre@...>
 

SodiusWillert has successfully implemented the OASIS Architecture Management Specification, Version 3.0, Project Specification revision 01 (https://docs.oasis-open-projects.org/oslc-op/am/v3.0/ps01/architecture-management-spec.html) dated 30 September 2021, in accordance with the conformance clauses defined in Section 5 "Conformance" of the specification. This use of the Architecture Management  specification is implemented in SECollab as well as OSLC Connect for Windchill, and includes interoperation with other similar independent implementations, as well as integration with tools supporting other OSLC specifications including OSLC Connect for Jira and Engineering Workflow Manager (Change Management), Rational DOORS Next Generation (Requirements Management), Engineering Test Manager (Quality Management).

Best regards, Sincères salutations,

François-Régis Jaunatre
OSLC Lab
34, Boulevard du Maréchal Alphonse Juin, 44100 Nantes, France
Ph: +33 (0) 2 28 23 55 23 |
sodiuswillert.com

Check out OSLC Connect for Jira & OSLC Connect for Windchill

 


Now: oslc-op Weekly Contributors Meeting - 02/24/2022 #cal-notice

oslc-op@lists.oasis-open-projects.org Calendar <noreply@...>
 

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 Event

Description:
oslc-op contributors weekly telecon. 


One tap audio Dial In: +15124022718,,,,2979764690# (US) or +498938038719,,,,2979764690# (Germany) Looking for a different dial in number? Please see: https://meet.jit.si/static/dialInInfo.html?room=oslc-op
Meeting ID: 2979764690#
 
The meeting minutes are edited in https://hackmd.io/@driib/oslc-op-minutes/edit
Previous minutes can be found under https://github.com/oslc-op/oslc-admin/tree/master/minutes/2019 

OASIS OSLC Open Project group home: https://lists.oasis-open-projects.org/g/oslc-op 
oslc-op GitHub Organization: https://github.com/oslc-op
Mailing list: oslc-op@... (archives: https://lists.oasis-open-projects.org/g/oslc-op)


Re: AllowedValues not visible in the specs

Andrii Berezovskyi
 

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

–Andrew

On 22 Feb 2022, at 12:25, Jad El-Khoury <jad@...> wrote:



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 Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Tuesday, 22 February 2022 10:31
To: Jad El-Khoury <jad@...>; oslc-op@...
Subject: RE: AllowedValues not visible in the specs

 

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 include URIs in the oslc_qm namespace.

 

The QM spec doesn’t say that the value represents an enumeration – a finite set of values. It only says it’s a string, and the values of that string are implementation defined. Whether that was the right choice is a separate design issue. We cannot change the spec now because that would be a breaking change. So the only thing we should do is remove the allowed values from that OSLC property.

Best regards,
David.

 

From: Jad El-Khoury <jad@...>
Sent: 22 February 2022 08:59
To: David Honey2 <david.honey@...>; oslc-op@...
Subject: [EXTERNAL] RE: AllowedValues not visible in the specs

 

Hi David I understood from you that enumeration values should have URIs, instead of xsd:string. And “com.ibm.rqm.execution.common.state.failed", for example, does classify as a valid URI. or do you mean that the URI be in the form ‍ ‍ ‍ ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi David

 

I understood from you that enumeration values should have URIs, instead of xsd:string. And “com.ibm.rqm.execution.common.state.failed", for example, does classify as a valid URI. or do you mean that the URI be in the form http://open-services.net/ns/qm#failed ?

 

But yes, the specs document should match the ttl file, so maybe we should remove that list if the specs does not define any.

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Monday, 21 February 2022 13:09
To: Jad El-Khoury <jad@...>; oslc-op@...
Subject: RE: AllowedValues not visible in the specs

 

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 such using URIs. But that doesn’t appear to be the intent of the spec.

 

The shape should not define any allowed values because the specification does not define any. The specification says that a server may implement any values it wants. These might not necessarily be a closed set. The allowed values don’t belong in oslc_qm:status at all.

 

From: Jad El-Khoury <jad@...>
Sent: 21 February 2022 12:04
To: David Honey2 <david.honey@...>; oslc-op@...
Subject: [EXTERNAL] RE: AllowedValues not visible in the specs

 

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 the given values be ok? ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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 the given values be ok?

 

I was looking for examples in other domains but allowedValues is not used so often.

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Monday, 21 February 2022 12:43
To: oslc-op@...; Jad El-Khoury <jad@...>
Subject: RE: AllowedValues not visible in the specs

 

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.common.state.passed" , "com.ibm.rqm.execution.common.state.deferred" , "com.ibm.rqm.execution.common.state.incomplete" , "com.ibm.rqm.execution.common.state.blocked" , "com.ibm.rqm.execution.common.state.part_blocked" , "com.ibm.rqm.execution.common.state.perm_failed" , "com.ibm.rqm.execution.common.state.error" ;

 

Also the value type is:

                               oslc:valueType           xsd:string ;

 

That seems like an error to me. All of those allowed values are specific to IBM’s ETM application.

The description of that property says:

“Used to indicate the state of the Test Result based on values defined by the service provider. Most often a read-only property.”

Using allowed values for a string value goes against general linked data guidance that says that enumeration values should have URIs. This means that the allowed values should be URIs, and may have a specific type that might defined as the oslc:range of that property.

 

I think you should submit a defect against that resource shape. Those allowed value should be removed.

 

David.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 21 February 2022 09:04
To: OASIS OSLC Open Project (oslc-op@...) <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] AllowedValues not visible in the specs

 

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl, I can see the allowedValue list for a TestResult.

But this is not seen in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.html#TestResultShape

 

I think such information is important to show in the specs that the people read. Does it make sense to add such info?

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 


IBM Statement Of Use - OASIS Architecture Management Specification 3.0

Jason Keirstead <Jason.Keirstead@...>
 

IBM has successfully implemented the OASIS Architecture Management Specification, Version 3.0, Project Specification revision 01 (https://docs.oasis-open-projects.org/oslc-op/am/v3.0/ps01/architecture-management-spec.html) dated 30 September 2021, in accordance with the conformance clauses defined in Section 5 "Conformance" of the specification. This use of the Architecture Management  specification is implemented in Rational Model Manager (RMM) and Rational Design Manager and includes interoperation with other similar independent implementations, as well as integration with tools supporting other OSLC specifications including Engineering Workflow Manager (Change Management), Rational DOORS Next Generation (Requirements Management), and Engineering Test Manager (Quality Management).

 

 

-
Jason Keirstead
Distinguished Engineer, CTO - IBM Security Threat Management |
www.ibm.com/security

Declare an Emergency: USA +1 888 241 9812, Global +1 312 212 8034

 

Assistant - Mauricio Durán Cambronero (mauduran@...)

See my calendar - https://ibm.biz/jkcalendar


Co-Chair - Open Cybersecurity Alliance, Project Governing Board

www.opencybersecurityalliance.org

 


Re: AllowedValues not visible in the specs

Jad El-Khoury
 

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 Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Tuesday, 22 February 2022 10:31
To: Jad El-Khoury <jad@...>; oslc-op@...
Subject: RE: AllowedValues not visible in the specs

 

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 include URIs in the oslc_qm namespace.

 

The QM spec doesn’t say that the value represents an enumeration – a finite set of values. It only says it’s a string, and the values of that string are implementation defined. Whether that was the right choice is a separate design issue. We cannot change the spec now because that would be a breaking change. So the only thing we should do is remove the allowed values from that OSLC property.

Best regards,
David.

 

From: Jad El-Khoury <jad@...>
Sent: 22 February 2022 08:59
To: David Honey2 <david.honey@...>; oslc-op@...
Subject: [EXTERNAL] RE: AllowedValues not visible in the specs

 

Hi David I understood from you that enumeration values should have URIs, instead of xsd:string. And “com.ibm.rqm.execution.common.state.failed", for example, does classify as a valid URI. or do you mean that the URI be in the form ‍ ‍ ‍ ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi David

 

I understood from you that enumeration values should have URIs, instead of xsd:string. And “com.ibm.rqm.execution.common.state.failed", for example, does classify as a valid URI. or do you mean that the URI be in the form http://open-services.net/ns/qm#failed ?

 

But yes, the specs document should match the ttl file, so maybe we should remove that list if the specs does not define any.

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Monday, 21 February 2022 13:09
To: Jad El-Khoury <jad@...>; oslc-op@...
Subject: RE: AllowedValues not visible in the specs

 

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 such using URIs. But that doesn’t appear to be the intent of the spec.

 

The shape should not define any allowed values because the specification does not define any. The specification says that a server may implement any values it wants. These might not necessarily be a closed set. The allowed values don’t belong in oslc_qm:status at all.

 

From: Jad El-Khoury <jad@...>
Sent: 21 February 2022 12:04
To: David Honey2 <david.honey@...>; oslc-op@...
Subject: [EXTERNAL] RE: AllowedValues not visible in the specs

 

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 the given values be ok? ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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 the given values be ok?

 

I was looking for examples in other domains but allowedValues is not used so often.

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Monday, 21 February 2022 12:43
To: oslc-op@...; Jad El-Khoury <jad@...>
Subject: RE: AllowedValues not visible in the specs

 

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.common.state.passed" , "com.ibm.rqm.execution.common.state.deferred" , "com.ibm.rqm.execution.common.state.incomplete" , "com.ibm.rqm.execution.common.state.blocked" , "com.ibm.rqm.execution.common.state.part_blocked" , "com.ibm.rqm.execution.common.state.perm_failed" , "com.ibm.rqm.execution.common.state.error" ;

 

Also the value type is:

                               oslc:valueType           xsd:string ;

 

That seems like an error to me. All of those allowed values are specific to IBM’s ETM application.

The description of that property says:

“Used to indicate the state of the Test Result based on values defined by the service provider. Most often a read-only property.”

Using allowed values for a string value goes against general linked data guidance that says that enumeration values should have URIs. This means that the allowed values should be URIs, and may have a specific type that might defined as the oslc:range of that property.

 

I think you should submit a defect against that resource shape. Those allowed value should be removed.

 

David.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 21 February 2022 09:04
To: OASIS OSLC Open Project (oslc-op@...) <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] AllowedValues not visible in the specs

 

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl, I can see the allowedValue list for a TestResult.

But this is not seen in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.html#TestResultShape

 

I think such information is important to show in the specs that the people read. Does it make sense to add such info?

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 


Re: AllowedValues not visible in the specs

David Honey2
 

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 include URIs in the oslc_qm namespace.

 

The QM spec doesn’t say that the value represents an enumeration – a finite set of values. It only says it’s a string, and the values of that string are implementation defined. Whether that was the right choice is a separate design issue. We cannot change the spec now because that would be a breaking change. So the only thing we should do is remove the allowed values from that OSLC property.

Best regards,
David.

 

From: Jad El-Khoury <jad@...>
Sent: 22 February 2022 08:59
To: David Honey2 <david.honey@...>; oslc-op@...
Subject: [EXTERNAL] RE: AllowedValues not visible in the specs

 

Hi David I understood from you that enumeration values should have URIs, instead of xsd:string. And “com.ibm.rqm.execution.common.state.failed", for example, does classify as a valid URI. or do you mean that the URI be in the form ‍ ‍ ‍ ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi David

 

I understood from you that enumeration values should have URIs, instead of xsd:string. And “com.ibm.rqm.execution.common.state.failed", for example, does classify as a valid URI. or do you mean that the URI be in the form http://open-services.net/ns/qm#failed ?

 

But yes, the specs document should match the ttl file, so maybe we should remove that list if the specs does not define any.

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Monday, 21 February 2022 13:09
To: Jad El-Khoury <jad@...>; oslc-op@...
Subject: RE: AllowedValues not visible in the specs

 

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 such using URIs. But that doesn’t appear to be the intent of the spec.

 

The shape should not define any allowed values because the specification does not define any. The specification says that a server may implement any values it wants. These might not necessarily be a closed set. The allowed values don’t belong in oslc_qm:status at all.

 

From: Jad El-Khoury <jad@...>
Sent: 21 February 2022 12:04
To: David Honey2 <david.honey@...>; oslc-op@...
Subject: [EXTERNAL] RE: AllowedValues not visible in the specs

 

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 the given values be ok? ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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 the given values be ok?

 

I was looking for examples in other domains but allowedValues is not used so often.

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Monday, 21 February 2022 12:43
To: oslc-op@...; Jad El-Khoury <jad@...>
Subject: RE: AllowedValues not visible in the specs

 

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.common.state.passed" , "com.ibm.rqm.execution.common.state.deferred" , "com.ibm.rqm.execution.common.state.incomplete" , "com.ibm.rqm.execution.common.state.blocked" , "com.ibm.rqm.execution.common.state.part_blocked" , "com.ibm.rqm.execution.common.state.perm_failed" , "com.ibm.rqm.execution.common.state.error" ;

 

Also the value type is:

                               oslc:valueType           xsd:string ;

 

That seems like an error to me. All of those allowed values are specific to IBM’s ETM application.

The description of that property says:

“Used to indicate the state of the Test Result based on values defined by the service provider. Most often a read-only property.”

Using allowed values for a string value goes against general linked data guidance that says that enumeration values should have URIs. This means that the allowed values should be URIs, and may have a specific type that might defined as the oslc:range of that property.

 

I think you should submit a defect against that resource shape. Those allowed value should be removed.

 

David.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 21 February 2022 09:04
To: OASIS OSLC Open Project (oslc-op@...) <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] AllowedValues not visible in the specs

 

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl, I can see the allowedValue list for a TestResult.

But this is not seen in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.html#TestResultShape

 

I think such information is important to show in the specs that the people read. Does it make sense to add such info?

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 


Re: AllowedValues not visible in the specs

Jad El-Khoury
 

Hi David

 

I understood from you that enumeration values should have URIs, instead of xsd:string. And “com.ibm.rqm.execution.common.state.failed", for example, does classify as a valid URI. or do you mean that the URI be in the form http://open-services.net/ns/qm#failed ?

 

But yes, the specs document should match the ttl file, so maybe we should remove that list if the specs does not define any.

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Monday, 21 February 2022 13:09
To: Jad El-Khoury <jad@...>; oslc-op@...
Subject: RE: AllowedValues not visible in the specs

 

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 such using URIs. But that doesn’t appear to be the intent of the spec.

 

The shape should not define any allowed values because the specification does not define any. The specification says that a server may implement any values it wants. These might not necessarily be a closed set. The allowed values don’t belong in oslc_qm:status at all.

 

From: Jad El-Khoury <jad@...>
Sent: 21 February 2022 12:04
To: David Honey2 <david.honey@...>; oslc-op@...
Subject: [EXTERNAL] RE: AllowedValues not visible in the specs

 

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 the given values be ok? ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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 the given values be ok?

 

I was looking for examples in other domains but allowedValues is not used so often.

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Monday, 21 February 2022 12:43
To: oslc-op@...; Jad El-Khoury <jad@...>
Subject: RE: AllowedValues not visible in the specs

 

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.common.state.passed" , "com.ibm.rqm.execution.common.state.deferred" , "com.ibm.rqm.execution.common.state.incomplete" , "com.ibm.rqm.execution.common.state.blocked" , "com.ibm.rqm.execution.common.state.part_blocked" , "com.ibm.rqm.execution.common.state.perm_failed" , "com.ibm.rqm.execution.common.state.error" ;

 

Also the value type is:

                               oslc:valueType           xsd:string ;

 

That seems like an error to me. All of those allowed values are specific to IBM’s ETM application.

The description of that property says:

“Used to indicate the state of the Test Result based on values defined by the service provider. Most often a read-only property.”

Using allowed values for a string value goes against general linked data guidance that says that enumeration values should have URIs. This means that the allowed values should be URIs, and may have a specific type that might defined as the oslc:range of that property.

 

I think you should submit a defect against that resource shape. Those allowed value should be removed.

 

David.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 21 February 2022 09:04
To: OASIS OSLC Open Project (oslc-op@...) <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] AllowedValues not visible in the specs

 

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl, I can see the allowedValue list for a TestResult.

But this is not seen in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.html#TestResultShape

 

I think such information is important to show in the specs that the people read. Does it make sense to add such info?

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 


Re: AllowedValues not visible in the specs

David Honey2
 

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 such using URIs. But that doesn’t appear to be the intent of the spec.

 

The shape should not define any allowed values because the specification does not define any. The specification says that a server may implement any values it wants. These might not necessarily be a closed set. The allowed values don’t belong in oslc_qm:status at all.

 

From: Jad El-Khoury <jad@...>
Sent: 21 February 2022 12:04
To: David Honey2 <david.honey@...>; oslc-op@...
Subject: [EXTERNAL] RE: AllowedValues not visible in the specs

 

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 the given values be ok? ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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 the given values be ok?

 

I was looking for examples in other domains but allowedValues is not used so often.

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Monday, 21 February 2022 12:43
To: oslc-op@...; Jad El-Khoury <jad@...>
Subject: RE: AllowedValues not visible in the specs

 

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.common.state.passed" , "com.ibm.rqm.execution.common.state.deferred" , "com.ibm.rqm.execution.common.state.incomplete" , "com.ibm.rqm.execution.common.state.blocked" , "com.ibm.rqm.execution.common.state.part_blocked" , "com.ibm.rqm.execution.common.state.perm_failed" , "com.ibm.rqm.execution.common.state.error" ;

 

Also the value type is:

                               oslc:valueType           xsd:string ;

 

That seems like an error to me. All of those allowed values are specific to IBM’s ETM application.

The description of that property says:

“Used to indicate the state of the Test Result based on values defined by the service provider. Most often a read-only property.”

Using allowed values for a string value goes against general linked data guidance that says that enumeration values should have URIs. This means that the allowed values should be URIs, and may have a specific type that might defined as the oslc:range of that property.

 

I think you should submit a defect against that resource shape. Those allowed value should be removed.

 

David.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 21 February 2022 09:04
To: OASIS OSLC Open Project (oslc-op@...) <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] AllowedValues not visible in the specs

 

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl, I can see the allowedValue list for a TestResult.

But this is not seen in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.html#TestResultShape

 

I think such information is important to show in the specs that the people read. Does it make sense to add such info?

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 


Re: AllowedValues not visible in the specs

Jad El-Khoury
 

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 the given values be ok?

 

I was looking for examples in other domains but allowedValues is not used so often.

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Monday, 21 February 2022 12:43
To: oslc-op@...; Jad El-Khoury <jad@...>
Subject: RE: AllowedValues not visible in the specs

 

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.common.state.passed" , "com.ibm.rqm.execution.common.state.deferred" , "com.ibm.rqm.execution.common.state.incomplete" , "com.ibm.rqm.execution.common.state.blocked" , "com.ibm.rqm.execution.common.state.part_blocked" , "com.ibm.rqm.execution.common.state.perm_failed" , "com.ibm.rqm.execution.common.state.error" ;

 

Also the value type is:

                               oslc:valueType           xsd:string ;

 

That seems like an error to me. All of those allowed values are specific to IBM’s ETM application.

The description of that property says:

“Used to indicate the state of the Test Result based on values defined by the service provider. Most often a read-only property.”

Using allowed values for a string value goes against general linked data guidance that says that enumeration values should have URIs. This means that the allowed values should be URIs, and may have a specific type that might defined as the oslc:range of that property.

 

I think you should submit a defect against that resource shape. Those allowed value should be removed.

 

David.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 21 February 2022 09:04
To: OASIS OSLC Open Project (oslc-op@...) <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] AllowedValues not visible in the specs

 

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl, I can see the allowedValue list for a TestResult.

But this is not seen in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.html#TestResultShape

 

I think such information is important to show in the specs that the people read. Does it make sense to add such info?

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 


Re: AllowedValues not visible in the specs

David Honey2
 

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.common.state.passed" , "com.ibm.rqm.execution.common.state.deferred" , "com.ibm.rqm.execution.common.state.incomplete" , "com.ibm.rqm.execution.common.state.blocked" , "com.ibm.rqm.execution.common.state.part_blocked" , "com.ibm.rqm.execution.common.state.perm_failed" , "com.ibm.rqm.execution.common.state.error" ;

 

Also the value type is:

                               oslc:valueType           xsd:string ;

 

That seems like an error to me. All of those allowed values are specific to IBM’s ETM application.

The description of that property says:

“Used to indicate the state of the Test Result based on values defined by the service provider. Most often a read-only property.”

Using allowed values for a string value goes against general linked data guidance that says that enumeration values should have URIs. This means that the allowed values should be URIs, and may have a specific type that might defined as the oslc:range of that property.

 

I think you should submit a defect against that resource shape. Those allowed value should be removed.

 

David.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 21 February 2022 09:04
To: OASIS OSLC Open Project (oslc-op@...) <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] AllowedValues not visible in the specs

 

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl, I can see the allowedValue list for a TestResult.

But this is not seen in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.html#TestResultShape

 

I think such information is important to show in the specs that the people read. Does it make sense to add such info?

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 


Re: AllowedValues not visible in the specs

David Honey2
 

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.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 21 February 2022 09:04
To: OASIS OSLC Open Project (oslc-op@...) <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] AllowedValues not visible in the specs

 

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl, I can see the allowedValue list for a TestResult.

But this is not seen in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.html#TestResultShape

 

I think such information is important to show in the specs that the people read. Does it make sense to add such info?

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 


AllowedValues not visible in the specs

Jad El-Khoury
 

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 example, in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.ttl, I can see the allowedValue list for a TestResult.

But this is not seen in https://oslc-op.github.io/oslc-specs/specs/qm/quality-management-shapes.html#TestResultShape

 

I think such information is important to show in the specs that the people read. Does it make sense to add such info?

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 


Re: Can/Should property constraints be non-local resources?

Jad El-Khoury
 

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 El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Friday, 18 February 2022 14:40
To: oslc-op@...; Jad El-Khoury <jad@...>
Subject: Re: Can/Should property constraints be non-local resources?

 

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

 


From: oslc-op@... <oslc-op@...> on behalf of Jad El-Khoury <jad@...>
Sent: Friday, February 18, 2022 12:00:14 PM
To: OASIS OSLC Open Project (oslc-op@...) <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] Can/Should property constraints be non-local resources?

 

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 constraint. For example, see https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/core-shapes.ttl ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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 constraint.

For example, see https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/core-shapes.ttl

 

but, when I read about the Core Common Properties (https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/core-shapes.html#CommonPropertiesShape), I would have expected these to be globally defined, so that other resource shapes can refer to them.

But this does not seem to be the case. The Core shapes (https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/core-shapes.ttl) only contains resource shapes with their own locally defined properties.

 

Does this mean that the table in section “2.1 Properties on Any Resource” is only textual, and has no equivalent in the ttl files?

Does this mean that it is not a good praxis to define property constraints globally?

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 


Re: Can/Should property constraints be non-local resources?

David Honey2
 

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


From: oslc-op@... <oslc-op@...> on behalf of Jad El-Khoury <jad@...>
Sent: Friday, February 18, 2022 12:00:14 PM
To: OASIS OSLC Open Project (oslc-op@...) <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] Can/Should property constraints be non-local resources?
 
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 constraint. For example, see https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/core-shapes.ttl ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd

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 constraint.

For example, see https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/core-shapes.ttl

 

but, when I read about the Core Common Properties (https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/core-shapes.html#CommonPropertiesShape), I would have expected these to be globally defined, so that other resource shapes can refer to them.

But this does not seem to be the case. The Core shapes (https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/core-shapes.ttl) only contains resource shapes with their own locally defined properties.

 

Does this mean that the table in section “2.1 Properties on Any Resource” is only textual, and has no equivalent in the ttl files?

Does this mean that it is not a good praxis to define property constraints globally?

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 


Can/Should property constraints be non-local resources?

Jad El-Khoury
 

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 constraint.

For example, see https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/core-shapes.ttl

 

but, when I read about the Core Common Properties (https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/core-shapes.html#CommonPropertiesShape), I would have expected these to be globally defined, so that other resource shapes can refer to them.

But this does not seem to be the case. The Core shapes (https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/core-shapes.ttl) only contains resource shapes with their own locally defined properties.

 

Does this mean that the table in section “2.1 Properties on Any Resource” is only textual, and has no equivalent in the ttl files?

Does this mean that it is not a good praxis to define property constraints globally?

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 


Approval of a Statement of Use for an OSLC Specification

Andrii Berezovskyi
 

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 to the OSLC Reference Implementation that contains the AM Server implementation.

/Andrew

Begin forwarded message:

From: Martin Törngren <martint@...>
Subject: RE: Approval of a Statement of Use for an OSLC Specification
Date: W7 17 February 2022 at 20:31:17 CET
To: Andrii Berezovskyi <andriib@...>

Hi Andrii, i am happy to approve of the statement.
Is this email sufficient or do you need it stated in any other way?

Just one question - what does "OSLC-OP" stand for? Would be relevant to spell this out/explain it?
Cheers
Martin

-----Original Message-----
From: Andrii Berezovskyi <andriib@...>
Sent: den 17 februari 2022 19:59
To: Martin Törngren <martint@...>
Subject: Approval of a Statement of Use for an OSLC Specification

Dear Martin,

Could you please approve the following statement to be submitted to OASIS:


KTH Royal Institute of Technology has successfully implemented the OASIS Architecture Management Specification, Version 3.0, dated 30 September 2021, in accordance with the conformance clauses defined in Section 5 "Conformance" of the specification. This use of the specification includes interoperation with other similar independent implementations, as well as integration with tools supporting other OSLC-OP specifications.


Thank you in advance!

/Andrew



Call for Statements of Use for OSLC Architecture Management Specification Version 3.0

Jim Amsden
 

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 with other lifecycle management tools, and user experience, while maintaining compatibility with other OSLC specifications. Implementations of this specification are therefore applicable for Statements of Use required to progress to OASIS Standard.

 

The OSLC Open Project is ready to accept Statements of Use from implementers. This is an essential part of the OASIS standardization process and will enable us to progress to OASIS Standard. Please see Section 14 of the OASIS Open Project Rules for more information. In summary:

 

Statement of Use“, with respect to a Committee Specification or Project Specification, is a written statement that a party has successfully used or implemented that specification in accordance with all or some of its conformance clauses, identifying those clauses that apply, and stating whether its use included the interoperation of multiple independent implementations. The Statement of Use must be made to a specific version of the Specification and must include the Specification’s approval date. The party may be an OASIS Member or a non-member. In case of a non-member, the Statement of Use must be submitted via the Technical Committee’s or Project Governing Board’s comment facility. A TC or PGB may require a Statement of Use to include hyperlinks to documents, files or demonstration transcripts that enable the committee’s members to evaluate the implementation or usage. A Statement of Use submitted to the TC or PGB must be approved by TC Resolution or PGB action as an acceptable Statement of Use with respect to the Specification. A party can only issue one Statement of Use for a given specification. When issued by an OASIS Organizational Member, a Statement of Use must be endorsed by the Organizational Member’s Primary Representative

 

Statements of Use must be endorsed by the OASIS Organizational Member's Primary Representative. Submitters just need to notify the OOSLC-OP PGB, by submitting their 'Statement of Use' to the oslc-op@... or oslc-op-pgb@... mailing lists. A typical statement of use could be:

 

<insert name / org here> has successfully implemented the OASIS Architecture Management Specification, Version 3.0, dated 30 September 2021, in accordance with the conformance clauses defined in Section 5 "Conformance" of the specification. This use of the specification includes interoperation with other similar independent implementations, as well as integration with tools supporting other OSLC-OP specifications.

 


Call for Statements of Use for OSLC Architecture Management Specification Version 3.0

Jim Amsden
 

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 with other lifecycle management tools, and user experience, while maintaining compatibility with other OSLC specifications. Implementations of this specification are therefore applicable for Statements of Use required to progress to OASIS Standard.

 

The OSLC Open Project is ready to accept Statements of Use from implementers. This is an essential part of the OASIS standardization process and will enable us to progress to OASIS Standard. Please see Section 14 of the OASIS Open Project Rules for more information. In summary:

 

Statement of Use“, with respect to a Committee Specification or Project Specification, is a written statement that a party has successfully used or implemented that specification in accordance with all or some of its conformance clauses, identifying those clauses that apply, and stating whether its use included the interoperation of multiple independent implementations. The Statement of Use must be made to a specific version of the Specification and must include the Specification’s approval date. The party may be an OASIS Member or a non-member. In case of a non-member, the Statement of Use must be submitted via the Technical Committee’s or Project Governing Board’s comment facility. A TC or PGB may require a Statement of Use to include hyperlinks to documents, files or demonstration transcripts that enable the committee’s members to evaluate the implementation or usage. A Statement of Use submitted to the TC or PGB must be approved by TC Resolution or PGB action as an acceptable Statement of Use with respect to the Specification. A party can only issue one Statement of Use for a given specification. When issued by an OASIS Organizational Member, a Statement of Use must be endorsed by the Organizational Member’s Primary Representative

 

Statements of Use must be endorsed by the OASIS Organizational Member's Primary Representative. Submitters just need to notify the OOSLC-OP PGB, by submitting their 'Statement of Use' to the oslc-op@... or oslc-pgb@... mailing lists. A typical statement of use could be:

 

<insert name / org here> has successfully implemented the OASIS Architecture Management Specification, Version 3.0, dated 30 September 2021, in accordance with the conformance clauses defined in Section 5 "Conformance" of the specification. This use of the specification includes interoperation with other similar independent implementations, as well as integration with tools supporting other OSLC-OP specifications.

 


Now: oslc-op Weekly Contributors Meeting - 02/17/2022 #cal-notice

oslc-op@lists.oasis-open-projects.org Calendar <noreply@...>
 

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 Event

Description:
oslc-op contributors weekly telecon. 


One tap audio Dial In: +15124022718,,,,2979764690# (US) or +498938038719,,,,2979764690# (Germany) Looking for a different dial in number? Please see: https://meet.jit.si/static/dialInInfo.html?room=oslc-op
Meeting ID: 2979764690#
 
The meeting minutes are edited in https://hackmd.io/@driib/oslc-op-minutes/edit
Previous minutes can be found under https://github.com/oslc-op/oslc-admin/tree/master/minutes/2019 

OASIS OSLC Open Project group home: https://lists.oasis-open-projects.org/g/oslc-op 
oslc-op GitHub Organization: https://github.com/oslc-op
Mailing list: oslc-op@... (archives: https://lists.oasis-open-projects.org/g/oslc-op)

301 - 320 of 1072