Objectives
Result - implementing an open source sysml2 server
Plan
Considerations
The purpose of the server is to store and retrieve SysML models based on the abstract syntax as defined in the SysML Spec.
The primary & initial interface to RDF repositories will utilize the open-api specification. As the project progresses, the following capabilities can be implemented in stages:
Generic “stubbed out” API server implementation
Push and retrieve full SysML-RDF models without regard to versioning – this can use generic RDF SparQL
Respect API versioning mapped to Flexo capabilities, which are still in pre-release.
Support the API capability for derived relationships
Support Diff/Merge
The current OSLC specification is not considered sufficient and has been replaced by the OASIS-OSLC team. Flexo may want to implement the OSLC interface, that will be looked at after the full API implementation.
We will use the same URIs between the UML/Flexo , OSLC, & API representations. There are technical and “political” considerations.
OSLC requires URIs that are not version-specific, this would also be preferable for Flexo. The OMG spec may also have version-specific URIs.
OSLC requires that the URIs be “dereferenceable”, thus if they are OMG URIs, OMG would have to host, at a minimum, the RDFS representation compatible with OSLC. Oasis typically hosts OSLC specifications with a Oasis namespace but has agreed to use the OMG namespace.
Besides open API and OSLC, an additional interface is possible via XMI.
Once we have the API and repository we can start work on UI and document generation.
There are issues with respect to retaining the order of lists in RDF, which are discussed below.
Current State
There is candidate OSLC / RDFS artifacts here:
There is a candidate draft OWL derived via OML, here: https://github.com/opencaesar/sandbox/blob/master/sysml2/owl/www.omg.org/spec/SysML.owl
There is an initial implementation of Flexo versioning that needs to be validated with the SysML Open-API versioning.
The “openapi.yaml” is able to generate API clients and servers using open tooling. The toolchain for producing this artifact and the generation patterns to use need to be solidified. There may be issues with the open-api spec
Specific tasks
Decide on the programming language to be used at each stage. For Flexo, Java is preferred
Pick an API framework, one with open-api support
Finalize and validate generated OWL
Finalize and validate generated OWLS spec, including TDFS
Setup repositories and dev environment
With the open-api document in the SysML spec, use open-api tool chain, produce a “Stubbed out server” – that is a server that responds to the API calls but has no backend implementation. This can then be leveraged and refined along multiple workstreams.
Document any issues with the open-api spec to be handled by the FTF/RTF
Define & implement additional test cases with a test framework
Implement a basic, non-versioned “put and get” of an entire SysML model using generic RDF/SparQL. This implements the mapping of the the API “model content” to RDF.
Implement versioning with Flexo utilizing the above mapping.
Implement API capability for diff/merge
Implement API capability for derived relations (discussion below)
Implement API Security, TBD, Consider OpenMBE approach.
Validate the system with test cases, existing clients & benchmark performance.
Timeframe goals
11/14/2024 - stubbed out API server implemented
12/19/2024 - Implement a basic, non-versioned “put and get” of an entire SysML
2/1/2025 - complete
RDF Representation specifics
Representing ordered lists in RDF
The SysML-V2 specification defines all properties and association ends with a multiplicity >1 as ordered. This ordering is important for the proper interpretation of SysML semantics and compatibility with other representations. There is no “native” list datatype in RDF, and there are various approaches to representing ordered lists, but none of them are ideal.
The Open-API uses JSON that is not Json-LD. It will be a requirement that the ordering implied by the JSON is preserved by whichever pattern we use in RDF. If JSON-LD were to be used in the API it would not preserve order as order is not specified in the RDF semantics.
Triple Reification Option (Agreed choice)
The RDF repository must retain the ordering semantics when persisting and retrieving SysML models. We will Use triple reification and, when/if it becomes standard, RDF-Star to make an ordering “statement” about each triple defining a collection. This would have the advantage that the OWL could properly express the range of a property, look “normal” and could be reasoned over for model validation. We would interpret the semantics of the Ordering annotation to imply the need for the reification. The consideration would be that each ordered element would take 6 triples. Also, there is no syntactic sugar for it (today) as there is with rdf:List.
The pattern would look like this:
#given
:r a SysML:Relationship.
:e a SysML:Element .
#This is the actual triple for the SysML:source property of a relationship
:r SysML:source :e .
# The following orders it with the addition of an "ordering" property defined for SysML.
:s_1 a rdf:Statement ;
rdf:subject :r ;
rdf:predicate SysMLsource;
rdf:object :e ;
Ordering:order 1 .
Based on the current RDF-Star draft, in the Turtle syntax, it would look something like:
<< :r SysML:source :e >> :Ordering:order 1 .
Justification: this option preserves “normal OWL” syntax & semantics with the ordering as an extension. Also, if SysML decides that not every list needs to be ordered, it could easily be removed without changing the core ontology. There will also be an annotation defining a property as ordered. If generated via OML, this ordering semantic would need to be in OML as well.
Committers
Cory Casanave, MDS - cory-c@modeldriven.com
Ed Seidewitz, MDS - ed-s@modeldriven.com