Date   

OSLC Tracked Resource Set v3.0 Project Specification 01 approved by the OSLC Open Project

Paul Knight
 

OASIS is pleased to announce that OSLC Tracked Resource Set Version 3.0 from the Open Services for Lifecycle Collaboration Open Project [1] has been approved as an OASIS Project Specification.

Managing change and configuration in a complex systems development lifecycle is very difficult, especially in heterogeneous environments that include homegrown tools, open source projects, and commercial tools from different vendors. The OSLC initiative applies World Wide Web and Linked Data principles to enable interoperation of change, configuration, and asset management processes across a product's entire application and product lifecycle.

The Tracked Resource Set protocol allows a server to expose a set of resources in a way that allows clients to discover that set of resources, to track additions to and removals from the set, and to track state changes to the resources in the set. The protocol does not assume that clients will dereference the resources, but they could do so. The protocol is suitable for dealing with sets containing a large number of resources, as well as highly active resource sets that undergo continual change. The protocol is HTTP-based and follows RESTful principles.

This Project Specification is an OASIS deliverable, completed and approved by the OP's Project Governing Board and fully ready for testing and implementation. The applicable open source licenses can be found in the project's administrative repository at https://github.com/oslc-op/oslc-admin/blob/master/LICENSE.md.

The specification and related files are available at:

OSLC Tracked Resource Set Version 3.0
Project Specification 01
07 February 2022

- OSLC Tracked Resource Set Version 3.0. Part 1: Specification
https://docs.oasis-open-projects.org/oslc-op/trs/v3.0/ps01/tracked-resource-set.html
https://docs.oasis-open-projects.org/oslc-op/trs/v3.0/ps01/tracked-resource-set.pdf

- OSLC Tracked Resource Set Version 3.0. Part 2: Vocabulary
https://docs.oasis-open-projects.org/oslc-op/trs/v3.0/ps01/tracked-resource-set-vocab.html
https://docs.oasis-open-projects.org/oslc-op/trs/v3.0/ps01/tracked-resource-set-vocab.pdf

- OSLC Tracked Resource Set Version 3.0. Part 3: Constraints
https://docs.oasis-open-projects.org/oslc-op/trs/v3.0/ps01/tracked-resource-set-shapes.html
https://docs.oasis-open-projects.org/oslc-op/trs/v3.0/ps01/tracked-resource-set-shapes.pdf

- OSLC Tracked Resource Set RDF Vocabulary definitions file:
https://docs.oasis-open-projects.org/oslc-op/trs/v3.0/ps01/trs-vocab.ttl

- OSLC Tracked Resource Set Resource Shape Constraints definitions file:
https://docs.oasis-open-projects.org/oslc-op/trs/v3.0/ps01/trs-shapes.ttl

Distribution ZIP file

For your convenience, OASIS provides a complete package of the specification and related files in a ZIP distribution file. You can download the ZIP file at:
https://docs.oasis-open-projects.org/oslc-op/trs/v3.0/ps01/trs-v3.0-ps01.zip

Members of the OSLC OP Project Governing Board approved this specification by Special Majority Votes [2] as required by the Open Project rules [3].

Our congratulations to the participants and contributors in the Open Services for Lifecycle Collaboration Open Project on their achieving this milestone.

========== Additional references:

[1] Open Services for Lifecycle Collaboration Open Project
https://open-services.net/

[2] Approval ballot:
- https://lists.oasis-open-projects.org/g/oslc-op-pgb/message/220

[3] https://www.oasis-open.org/policies-guidelines/open-projects-process/
--

Paul Knight

Document Process

OASIS Open


+1 781 425 5073
paul.knight@...
www.oasis-open.org


Re: Now: oslc-op Weekly Contributors Meeting - 03/03/2022 #cal-notice

Andrii Berezovskyi
 

Minutes: https://github.com/oslc-op/oslc-admin/blob/master/minutes/2022/2022-03-03.md

 

From: <oslc-op@...> on behalf of "oslc-op@... Calendar" <noreply@...>
Reply-To: "oslc-op@..." <oslc-op@...>, "noreply@..." <noreply@...>
Date: Thursday, 3 March 2022 at 16:00
To: "oslc-op@..." <oslc-op@...>
Subject: [oslc-op] Now: oslc-op Weekly Contributors Meeting - 03/03/2022 #cal-notice

 

oslc-op Weekly Contributors Meeting

When:
03/03/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)


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

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

oslc-op Weekly Contributors Meeting

When:
03/03/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: Errata in OSLC Quality Management Specification Version 2.1 OASIS Standard 19 January 2022

Chet Ensign
 

Sounds good to me. We can go with that. 

/chet

On Thu, Feb 24, 2022 at 4:07 PM Paul Knight <paul.knight@...> wrote:
Hi all,

Here are my initial comments, subject to Chet's review:

Since the files for this OASIS Standard have not yet been installed and announced, I think we can handle this without issuing Errata.

I would suggest something like a "README" text file included in the publication directory, to note that line 240 of this file has been corrected, and now differs from the file approved by the membership of OASIS during the "Call for Consent". (i.e., the file at https://docs.oasis-open-projects.org/oslc-op/qm/v2.1/ps01/quality-management-shapes.ttl)

We could also include similar language in the announcement of the publication of the OS.

Best regards,
Paul

On Thu, Feb 24, 2022 at 2:44 PM Jim Amsden <jamsden@...> wrote:

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?

 

 



--

Paul Knight

Document Process

OASIS Open


+1 781 425 5073
paul.knight@...
www.oasis-open.org


--

Chet Ensign

Chief Technical Community Steward

OASIS Open

   
+1 201-341-1393
chet.ensign@...
www.oasis-open.org


Re: Request for SMV to promote OSLC Architecture Management Specification Version 3.0, PS01 to Candidate Oasis Standard

Chet Ensign
 

On Thu, Feb 24, 2022 at 2:55 PM Jim Amsden <jamsden@...> wrote:

The oslc-op wishes to request a Special Majority Vote for the PGB to approve the OSLC Open Project Architecture Management 3.0 Specification, Project Specification revision 01 as a Candidate OASIS Standard. The PGB has received the required three Statements of Use.

 

 

 

 



--

Chet Ensign

Chief Technical Community Steward

OASIS Open

   
+1 201-341-1393
chet.ensign@...
www.oasis-open.org


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

Paul Knight
 

Hi all,

Here are my initial comments, subject to Chet's review:

Since the files for this OASIS Standard have not yet been installed and announced, I think we can handle this without issuing Errata.

I would suggest something like a "README" text file included in the publication directory, to note that line 240 of this file has been corrected, and now differs from the file approved by the membership of OASIS during the "Call for Consent". (i.e., the file at https://docs.oasis-open-projects.org/oslc-op/qm/v2.1/ps01/quality-management-shapes.ttl)

We could also include similar language in the announcement of the publication of the OS.

Best regards,
Paul

On Thu, Feb 24, 2022 at 2:44 PM Jim Amsden <jamsden@...> wrote:

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?

 

 



--

Paul Knight

Document Process

OASIS Open


+1 781 425 5073
paul.knight@...
www.oasis-open.org


Request for SMV to promote OSLC Architecture Management Specification Version 3.0, PS01 to Candidate Oasis Standard

Jim Amsden
 

The oslc-op wishes to request a Special Majority Vote for the PGB to approve the OSLC Open Project Architecture Management 3.0 Specification, Project Specification revision 01 as a Candidate OASIS Standard. The PGB has received the required three Statements of Use.

 

 

 

 


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

 

281 - 300 of 1059