← Prev in month ← Prev in thread

OSLC CORE TC Minutes Jan 17 2019

From
Martin Sarabura <>
Date
2019-01-17T16:12:43+00:00
ID
CAJhnejD0MkJipX=5a76c29tja7TGjsnd-7Wo=B=
Thread
OSLC CORE TC Minutes Jan 17 2019
This meeting was combined with the OSLC domains meeting. Martin S joined at the top of the hour.

[14:36] GrayBachelor (IBM): Attendees: Jim, Nick, Gray, Andrew

[14:38] Andrew Berezovskyi (KTH): last posted minutes

[14:38] Andrew Berezovskyi (KTH): https://lists.oasis-open.org/archives/oslc-domains/201812/msg00006.html

[14:39] GrayBachelor (IBM): Thanks Andrew

[14:41] GrayBachelor (IBM): The above minutes are for 13/12/18

[14:44] GrayBachelor (IBM): The last meeting was 10th Jan

[14:46] Andrew Berezovskyi (KTH): https://lists.oasis-open.org/archives/oslc-domains/201901/msg00005.html

[14:46] GrayBachelor (IBM): Minutes approved

[14:47] GrayBachelor (IBM): Remaining QM issues

[14:47] Jim Amsden: dcterms:relation, was added to QM 2.1,
 is not defined in QM 2.0 - this property is not in AM, RM or CM. Does 
RQM need this property? Is there any harm in adding it?

oslc:shortId and oslc:shortTitle are not defined in QM 2.0 - is defined 
in CM, RM and AM. Useful for resource preview, should be added.

oslc_qm:relatedChangeRequest, and many other QM relationship properties 
specify specific ranges in 2.0 that are any in 2.1. These range 
properties should be oslc:AnyResource. But should the more specific 
ranger constraints be retained for compatibility?

Should all the rdfs:seeAlso properties be removed from the vocabularies 
as we did in core since these are all OSLC 2.0 references.

Should rdfs:range properties be removed from all vocabulary properties 
as we did in OSLC core and CM? Some properties have multiple range 
values which created a ShapeChecker error.

The property constraints for QM resources have oslc:valueShape 
properties that refer to internal CE resource shapes. Should these be 
removed, or updated to reference the standard QM shapes? For     
oslc:valueShape oslc_rm:RequirementCollection ; Is this incorrect since 
its referencing the vocabulary class, not the shape?

oslc_qm:status property is defined in the QM shapes, but isn't in the 
vocabulary.

[14:48] GrayBachelor (IBM): dcterms:relation leave as-is in 2.1

[14:48] GrayBachelor (IBM): oslc:shortId and oslc:shortTitle leave as-is in 2.1

[14:55] GrayBachelor (IBM): Leave oslc range of other QM 
properties as-is as it is used e.g. by report builder and Lyo Designer 
uses them directly (MUST). Oslc range is SHOULD not MUST.

[14:57] GrayBachelor (IBM): Range is the expected target but not definitive

[14:59] Andrew Berezovskyi (KTH): The 
<code>oslc:range</code> for the colorConstraint is set to 
Color, meaning the value of the applicable property is constrained to be
 of <code>rdf:type</code> Color.

[14:59] GrayBachelor (IBM): There is a difference between appearance in the Shape (SHOULD) and in the Vocab the wording of the range "allowed" is more MUST

[14:59] Andrew Berezovskyi (KTH): https://github.com/oasis-tcs/oslc-core/blob/master/specs/core-vocab.html

[15:00] GrayBachelor (IBM): Andrew will raise an Issue to propose its resolution as MUST or SHOULD

[15:04] GrayBachelor (IBM): seeAlso - the destinations link need to be updated to 2.1 but have been removed from other vocabs - so agree removal

[15:05] GrayBachelor (IBM): Adding Martin S as attendee

[15:05] GrayBachelor (IBM): Post meeting notes to domain and core

[15:11] GrayBachelor (IBM): ref seeAlso: Andrew raised the
 topic of import into say Protege and a link to the source is useful 
rdfs seeAlso on the ontology not at a fine grained level > Andrew to 
check

[15:12] GrayBachelor (IBM): Nick will do the relative link conversion to deal with broken links

[15:13] GrayBachelor (IBM): (This arose from dialog about broken links around QM) Nick will do this in Respec

[15:20] GrayBachelor (IBM): Remove the non-OASIS properties in the shape and those that point to type or e.g. localhost

[15:23] GrayBachelor (IBM): status property is an over sight and will be added

[15:23] GrayBachelor (IBM): Gray has begun (at last) to finalise the proposal over the QM2.0 vs RM2.1 choices and will get with Jim offline to finish this

[15:28] GrayBachelor (IBM): In terms of choice ahead for 
Open Project Spec :prefer to use for updates to a completed Spec rather 
than for example our other non-published Specs (Cfg and TRS) to enable a
 consistent process to be found

[15:29] GrayBachelor (IBM): prefer to use

[15:31] GrayBachelor (IBM): Discussion on migration of 
issues - and the number of repos - we have Domain and Core today- there 
is some limit and so Jim will investigate if it can be staged to avoid 
having two places to work

[15:33] GrayBachelor (IBM): Andrew has faced this with Lyo in that each issue needs tagging for the Project across multiple repors

[15:36] GrayBachelor (IBM): The volume of work seems to point to a single repos

[15:36] GrayBachelor (IBM): Jim will propose that

[15:40] GrayBachelor (IBM): Andrew asks for feedback on ease of finding the issues to personally deal with and the unclaimed issues

[15:40] GrayBachelor (IBM): There could be a trend for use of GitHub in the Open Project setting

[15:42] GrayBachelor (IBM): https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=oslc-promcode

[15:44] Andrew Berezovskyi (KTH): https://lists.oasis-open.org/archives/oslc-promcode/
https://tools.oasis-open.org/version-control/browse/wsvn/oslc-promcode/WorkingDrafts/?rev=295&sc=1#_WorkingDrafts_

[15:44] GrayBachelor (IBM): Nick raised the fact that there will be a lot of updating needed to correctly drive ReSpec when the migration is done

[15:46] GrayBachelor (IBM): Nick is currently working on checking the TRS draft

[15:47] GrayBachelor (IBM): Nick's TRS draft should be available before end of Jan

[15:48] GrayBachelor (IBM): Nick has also changes to propose changes to CfgM around consistency for Change Set handling

[15:48] GrayBachelor (IBM): CorrectionNick has also has draft changes to propose for CfgM around consistency for Change Set handling

[15:51] GrayBachelor (IBM): Paul S has sent a list of issues with the OSLC Query proposal

[15:53] Andrew Berezovskyi (KTH): https://github.com/oasis-tcs/oslc-core/issues/7

[15:53] Andrew Berezovskyi (KTH): https://github.com/oasis-tcs/oslc-core/issues/8

[15:54] GrayBachelor (IBM): What checks can be made on checking the reference links or avoid adding the redirect (to the archive)

[15:55] Andrew Berezovskyi (KTH): https://www.evernote.com/l/ACrp7dPPwuNGqK03Ix48DXcWQGNAXsS4xPM

[15:58] GrayBachelor (IBM): Andrew: There is an effort for Permanent URLs which  is done via service

[15:59] GrayBachelor (IBM): archive.org

[16:00] Andrew Berezovskyi (KTH): https://www.wikiwand.com/en/Persistent_uniform_resource_locator
https://archive.org/services/purl/https://w3id.org/

[16:00] GrayBachelor (IBM): Andrew to make a proposal

[16:00] Andrew Berezovskyi (KTH): https://w3id.org/

[16:01] Jim Amsden: https://github.com/OSLC/oslc-site-hugo/issues/225

[16:01] Andrew Berezovskyi (KTH): http://purl.org/oslc/core

[16:02] GrayBachelor (IBM): Its the links within the specs that are breaking

[16:03] Andrew Berezovskyi (KTH): https://archive.open-services.net/bin/view/Main/OslcCoreSpecification.html

[16:03] GrayBachelor (IBM): Andrew checked the links for Core 3.0 and its OK

[16:07] Martin Sarabura: Agenda for next week: Config management and more on open project
← Prev in month ← Prev in thread