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

oslc-core message