You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Lothar Klein <lo...@lksoft.com> on 2021/06/09 12:07:17 UTC
Champion and Mentors wanted for new potential Apache SST incubator
project
Dear IPMC members,
We are looking for a Champion and Mentors for the new SST incubator project proposal; see below.
So far I contacted Justin Mclean and Christofer Dutz and they are considering to become mentors.
Best Regards
Lothar
=== Abstract ===
SST (Semantic STEP Technology) is an optimized RDF/OWL API with
GIT like revision control capabilities as an enabler for a new
comprehensive CAD/CAx data model derived from ISO 10303 (STEP)
and ISO 15926 (Oil & Gas) standards.
=== Rationale: The Problem to solve ===
There are many different kinds of Computer-aided technology
(CAx) systems around. Some are listed here:
=> https://en.wikipedia.org/wiki/Computer-aided_technologies
For all organizations that are involved in the design,
production, maintenance and commercial use of industrial
products a smooth exchange of data between these tools would be
needed. Also please have in mind that for most industrial
production a big supply network has be coordinated; each with
it’s own specific tools.
The reality is that data exchange between these system is often
not possible and if available the interface tools are
incomplete as they exchange only some, but not all needed data.
The problem get even worse as often the systems have to be used
in a cyclic iterative way to deal with design changes. The
truth is also that for all CAx systems a big part of the
software development power (if not the biggest part) is spent
on the interfaces to other system, not on the core
functionality the system provides.
STEP is a big attempt to address this issue. In the
introduction of ISO 10303-1:1994 "Overview and fundamental
principles" and extended in the 2021 edition we can read:
"ISO 10303 is an International Standard for the
computer-interpretable representation of product information
and for the exchange of product data. The objective is to
provide a neutral mechanism capable of describing products
throughout their life cycle. This mechanism is suitable not
only for neutral file exchange, but also as a basis for
implementing and sharing product databases, and as a basis for
archiving. The information generated about a product during its
design, manufacture, use, maintenance, and disposal is used for
many purposes. The use can involve many computer systems,
including some that can be located in different organizations.
In order to support such uses, organizations need to be able to
represent their product information in a common
computer-interpretable form that is required to remain complete
and consistent when exchanged among different computer
systems."
=> https://www.iso.org/obp/ui/#iso:std:iso:10303:-1:ed-2:v1:en
In the introduction of ISO 15926-1:2004 "Overview and
fundamental principles" we can see slightly different but
highly overlapping goals:
=> https://www.iso.org/obp/ui/#iso:std:iso:15926:-1:ed-1:v1:en
The goals of the ISO 10303 and 15926 series of standards are
only very partially achieved in practice today.
The aim of the SST project is to make the visions of these
standards a reality by providing an open source environment
that is suitable to directly operate on distributed data on servers
managed by different organizations.
=== Background ===
ISO 10303 and ISO 15926 and other series of standards are
developed by the ISO Technical Committee 184: Automation
Systems and Integration, Subcommittee 4: Industrial data. In
its resolution number 9 from March 1985 the overall goal was
expressed as: "To develop as soon as possible a single
international standard for the exchange of product definition
data to be called the standard for the exchange of product
model data (STEP)." It took almost 10 years (1994/95) till the
publication of the first set of standards. The geometric data
models and assembly structures developed back then are today
widely implemented by CAD and other systems. Since then the
STEP standard grew constantly with lots of new application
areas and layers of abstraction; but with only a few of the new
capabilities really implemented and widely used. For upward
compatibility reasons the originals data models where kept in
place with only minor extensions.
In parallel to the development of STEP, the process industry
was searching for ways to capture the life-cycle data for their
process plants. As ISO 10303 misses to capture the things
around us in a clear and precise way they developed the ISO
15926 series of standards that are based on a 4D data model,
allowing to fully capture things in time and space. The generic
data model in part 2 was released in 2003, and now there is
part 12 with a mapping to OWL:
ISO/TS 15926-12:2018 Industrial automation systems and
integration — Integration of life-cycle data for process plants
including oil and gas production facilities — Part 12:
Life-cycle integration ontology represented in Web Ontology
Language (OWL)
There had been a number of attempts to implement ISO 10303 and
ISO 15926 on the basis of OWL/RDF technologies; but they all
have in common that their performance is relatively low. This
is on one hand caused by the way on how the data models are
mapped to OWL, but are also caused by APIs such as Jena that
are not optimized for this kind of data.
=== Proposal ===
The Semantic STEP Technology (SST) establishes a novel way to
operate with industrial product data as it is needed in
CAD/CAM/CAx systems, part libraries, product live cycle system
and similar product management systems. SST focuses to record
and integrate all aspects of particular products such as
machines, vehicles, buildings, electronics, piece parts in all
their life cycle faces (e.g. requirements, design,
manufacturing and planning, usage, maintenance, dismantling).
Data is recorded and integrated in a computer sensible way so
that computer systems can process the data and make decisions
on what to do without direct human intervention. SST has a
small memory footprint, allows fast traversing of application
data in any direction and is implemented in the GO programming
language. SST is optimized for web services and cloud
computing, but is also suitable for traditional single user
applications.
The SST data models directly support data models that are
defined in the ISO 10303 series of standards. ISO 10303 is
widely known as STEP which stands for "STandard for the
Exchange of Product model data". Unfortunately there are some
disadvantages with STEP; primarily week semantic definitions,
several modelling layers that are more or less replicating the
lower layers in some modified way and widely overlapping
Application Protocols (AP); resulting in a standard that is
much more complex than it needs to be.
To address the issue with week semantic definitions in STEP,
the SST data model is founded on the 4D data model of ISO
15926, the standard for "Integration of life-cycle data for
process plants including oil and gas production facilities".
The 4D data model is a superior model to support all
disciplines, supply chain company types and life cycle stages,
regarding information about functional requirements, physical
solutions, types of objects and individual objects as well as
activities. However ISO 15926 misses the design specific
aspects that STEP is focusing on to a big degree. A
disadvantages of ISO 15926 is that it fully relies on class
membership to state that several objects share common
characteristics. This results in wide use of 2nd and 3rd degree
higher level classes (named such as class_of_class_of_xxx) that
are quite hard to follow and that are not very suitable for
practical data exchange. SST replaces most of these higher
level classes and relationships by modelling most application
objects as individuals, including designs. Instead of using
class membership, SST is using the "isDefinedBy" relationship
to state that e.g. a physical individual is defined by a design
individual (knowing that there are always some smaller or
bigger deviations).
For the implementation basis SST relies on the Semantic Web
standards from W3C such as RDF RDFS and OWL. Basis is the
mapping provided in part 12 of ISO 15926, "Life-cycle
integration ontology represented in Web Ontology Language
(OWL)". SST is using this mapping, but is adding additional
constraints to support efficient implementations. So not every
RDF data set is suitable to be managed by SST. The main
constraints are:
* every subject of a triple must have a base URI that is the
same as the NamedGraph it is used in
* splitting of data into NamedGraph for each application object
that can be managed independently (e.g. a part of a part
library, an organization, an assembly design)
* NamedGraph have to import import other NamedGraphs for needed
application objects by owl:imports (e.g. an assembly design
imports parts)
* NamedGraph are stored internally in a binary normalized
(canonical) format that is optimized for very fast loading,
saving, diff and merge operations
* application data uses for the base URIs random UUID-URNs and
also random UUIDs for the fragments
* extensive use of punning, even for application data
=> https://www.w3.org/TR/owl2-new-features/#F12:_Punning
* revision control is realized for Namespaces (a collection of
NamedGraph), very similar to GIT
* replication of Namespaces and history to other servers
realized very similar to GIT
=== Initial Goals or the Mission ===
To turn SST into an Apache top level project, the following
features should be implemented for a 1.0 release:
* Data Model adoptions to OWL and integration in SST-dictionary
for early binding:
-- ISO 15926-12
-- STEP integrated resources for representation (part43),
geometry & topology (part 42) and more
-- core parts of the STEP AP242ed2 DO-model
-- ISO 80000 Quantities and units
-- formal SST schema with full constraints
(similar to the capabilities Express but for OWL)
* Internal data storage in binary form:
-- NamedGraph
-- Diff between two NamedGraph
-- Complete/partial history of a NamedGraph
(including several NamedGraphs and Diffs sections)
-- Complete stage (all NamedGraph together)
* CRUD API:
-- late binding (references to resources are not checked)
-- early binding (references to resources are checked through
compiled dictionary)
-- undo / redo since last commit
* GIT like functionality:
-- user identification, authorization, authentication;
-- storage of Commit (user, timestamp, comment, Namespace
with all involved NamedGraphs);
-- storage of versions of NamedGraphs and Diffs under
their checksum (SHA1 or SHA256);
-- replication of Namespaces with history to other
repositories (via packed file);
-- delta update to/from remote repository
* Tools:
-- compiler to convert schema level ontologies into
early binding applications
-- schema level validation; e.g. using SHACL
-- generic filtering and extraction, e.g. using SPARQL
-- filling NoSQL DB with derived information for general
searching
* Import & Export:
-- Turtle (*.ttl) files
-- STEP part 21 files along AP242 (MIM level)
for geometric models and assemblies
-- STEP AP242 XML files for certain application areas
* Applications:
-- generic web-based viewer and editor to SST data
-- generic STEP viewer for parts, assembly structures
-- 3D viewer of already tessellated data
=== Current Status ===
After many years of working in this field and trying out new
approaches, the real implementation of this proposal in the GO
programming language started from scratch in January 2021 by a
core team of two persons.
For end of June 2021 a full functional prototype is available
consisting of the:
* core API in late and early binding with complete CRUD
functionality
* binary RDF file handling for NamedGraphs and Diffs
* import & export of Turtle files (*.ttl)
* STEP AP242 XML import
* a generic Web-Viewer onto the data
* and more is available
These capabilities are sufficient to start with the
implementation of first SST applications.
Next major things to implement are generic query capabilities
(SPARQL), testing for schema level conformance (e.g. SHACL),
GIT like functionalities for merging and replication, NoSQL DB
adoption for querying derived information.
** Meritocracy **
So far the SST project grew up in the non public by two
persons; each having a different focus. It is clear that this
phase is ending when SST is turned into an Apache incubator
project.
There are many potential SST extensions and application areas
inside and outside of the ASF that can only be managed by a
real community.
** Community **
In the early days of STEP many universities, research
institutes and CAD related companies where involved in the
development and implementation of the STEP standard. This is
partly documented in the book "The Grand Experience" from
Sharon J. Kemmerer, NIST, 1999. But as the implementations got
more mature, the strong growth in complexity of the standard
and the endless time needed to get consensus and run through
the standardization process, the number of participants got
smaller and smaller.
Today, as most of the original planned capabilities had been
finally standardized, and there is a new way to implement STEP
using RDF/OWL on the basis of a major parts of ISO/TS 15926-12,
there is a good chance that a new community will come together;
especially as today the integration of all these data on the
Internet is so much demanded.
There are already several communities around for which SST may
play a role, e.g.:
* MBx / CAx-IF implementor forum
=> https://www.cax-if.org/index.php
* LOTAR, Long Term Archiving and Retrieval
=> https://lotar-international.org/
* POSC Caesar Association
=> https://www.posccaesar.org/
** Core Developers **
The core developers are Vaidas Nargelas for the central GO code
and Lothar Klein for the STEP data model and converter.
** Alignment **
Other than standard GO libraries, SST is not really dependent
on other packages. However SST requires a second NoSQL DB with
derived information for which one of the Apache projects might
be used (maybe Apache Solr). Also it is clear that SST cloud
applications (e.g. micro services) will require several of the
capabilities provided by Apache.
For some potential SST applications a linkage via Apache PLC4X
might be used to directly drive production lines or a single NC
machine from data stored in SST.
** Known Risk **
Failure to set up a developer community
** Project Name **
We think that "Semantic STEP" is an appropriate naming of the
project as it clearly links with the W3C "Semantic Web"
standards and is clearly indicating the application area
"STEP".
Within the code we widely use the prefix to indicate the GO
packages:
* sst for the core API
* ssowl for the OWL ontology
* sslci for the adopted life-cycle ontology from ISO 15926
* ssont for the adopted STEP ontology
* ssrep for the adopted STEP representation models
(e.g. geometry & topology)
* etc.
There are no trademarks on "Semantic STEP", however there are
several trademarks for "SST". But as these letters are so
generic there should be no conflict when using "Apache SST".
Also there are several web-domains registered such as:
* semantic-step.net and semanticstep.net
* semantic-step.org and semanticstep.org
The sponsoring entity is ready to transfer these domains to ASF
is this proposal is accepted
** Orphaned products **
Both, Lothar Klein (Germany) and Vaidas Nargelas (Lithuania)
have a long term commitment to make SST a success.
** Inexperience with Open Source **
Back in 2013 the committers have already released JSDAI under
the AGPL v3 license (see www.jsdai.net). "J" stands for Java
and "SDAI" stands for the "Standard Data Access Interface";
primarily an API according to:
ISO/TS 10303-27:2000 Industrial automation systems and
integration — Product data representation and exchange
— Part 27: Implementation methods: Java TM programming
language binding to the standard data access interface
with Internet/Intranet extensions
=> https://sourceforge.net/projects/jsdai/
=> https://jsdai.net/
** Length of Incubation **
maybe 6 to 12 month till the point that an initial community
has formed and a first release with all core components is
available.
** Homogenous Developers **
The two initial founders of SST have quite different focuses
and experiences.
It is clear that during the incubation time the focus must be
to build up a community. As the proposers have various contacts
to universities and industry around the world this should be
feasible over some time.
However there is the chicken-egg problem. So first SST needs to
become an official Apache incubator project to make people
interested and ensure them that this is real opens software
with an open community.
** Reliance on Salaried Developers **
So far the SST development is sponsored by LKSoftWare GmbH and
the expectations is that this continues.
** Relationship with Other Apache Products **
Currently there are no dependencies on other ASF projects but
Apache Solr and Apache Cassandra are being considered.
** A Excessive Fascination with the Apache Brand **
So far SST was developed without considering to make it an ASF
project. Weighting the pros and cons we come to the conclusion
that as an ASF project SST has a much bigger chance to make it
a success; especially because only in this case we can hope
that SST is widely used to publish industrial product data in a
computer sensible way on the Internet.
** Documentation **
Not ready today. More detailed SST documentation will become
available when in incubator stage.
** Initial Source **
All source files (GO, Turtle) are currently stored in an
internal GIT of LKSoftWare GmbH.
Source and Intellectual Property Submission Plan
All is currently under copyright of LKSoftWare GmbH.
Will be moved over to ASF when this podling application is
successful.
** External Dependencies **
No
** Cryptography **
There is no cryptography involved in the core code-base.
=== Required Resources ===
** Mailing lists: **
Needed lists are private@..., dev@..., commits@...
** Subversion Directory **
No
** Git Repositories **
Yes
** Issue Tracking **
JIRA
** Other Resources **
A Wiki for the documentation
** Initial Committers **
Vaidas Nargelas <va...@gmail.com>
Lothar Klein <lo...@lksoft.com>
=== Sponsors ===
** Champion: **
TBD
** Nominated Mentors: **
TBD
** Sponsoring Entity: **
TBD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Champion and Mentors wanted for new potential Apache SST incubator project
Posted by Vaidas Narg��las <va...@gmail.com>.
Hi All,
SST is primarily not a STEP files import tool/API even though it is able to do so. It is going to be RDF/OWL API + GIT like revision based repository environment that allows to work with CAD/CAx RDF data in a distributed way. It has a lot of generic RDF capabilities but is optimized for CAD/CAx workflows.
Vaidas
On 2021/06/11 14:11:46, Lothar Klein <lo...@lksoft.com> wrote:
> Hello Chris,
>
> Just before I responded about STEP geometry.
> Another potential application is about assembly structures. Today likely all reasonable CAD systems can generate STEP files with assembly information. SST can already import XML files with assemblies (but not yet p21 files with assemblies). A potential application might e.g. reads in a STEP assembly for a machine and then analyses all the parts the machine is made up from and their transformation/placement in space. A future SST application might e.g.:
>
> a) try to find vendors on the Internet that offer suitable parts and link to them - e.g. link to their more detailed STEP models they provide on the Internet (many do so already)
>
> b) collect how many pieces of the same parts are needed (e.g. number of screws of a certain type) and from this derive a BOM (Bill Of Material), containing a summary of the more detailed assembly information.
>
> c) Develop a tool to simulate how the assembly could be best build up; the sequence of operations that are needed. The result could be similar to what you see is coming with a LEGO(tm) toy with all the single steps on how to put things together.
>
> The result of all three examples could be again stored in SST and be used by further tools.
>
> Lothar
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Champion and Mentors wanted for new potential Apache SST incubator project
Posted by Lothar Klein <lo...@lksoft.com>.
Hello Chris,
Just before I responded about STEP geometry.
Another potential application is about assembly structures. Today likely all reasonable CAD systems can generate STEP files with assembly information. SST can already import XML files with assemblies (but not yet p21 files with assemblies). A potential application might e.g. reads in a STEP assembly for a machine and then analyses all the parts the machine is made up from and their transformation/placement in space. A future SST application might e.g.:
a) try to find vendors on the Internet that offer suitable parts and link to them - e.g. link to their more detailed STEP models they provide on the Internet (many do so already)
b) collect how many pieces of the same parts are needed (e.g. number of screws of a certain type) and from this derive a BOM (Bill Of Material), containing a summary of the more detailed assembly information.
c) Develop a tool to simulate how the assembly could be best build up; the sequence of operations that are needed. The result could be similar to what you see is coming with a LEGO(tm) toy with all the single steps on how to put things together.
The result of all three examples could be again stored in SST and be used by further tools.
Lothar
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Champion and Mentors wanted for new potential Apache SST incubator project
Posted by Lothar Klein <lo...@lksoft.com>.
Hello Nathan,
Right, STEP geometry is one of the things we could do with SST. We are just finishing with a higher level ontology that is directly derived from STEP geometry models (written in the Express modelling language) and that is directly integrated in SST as "early binding". So an application can directly operate on objects such an Ellipse, a BSplineSurfaceWithKnots,a Torus or to take advantage of the new triangulated data capabilities.
The next thing to do is to write a STEP p21-file parser that can transform the data in a p21 file into RDF using the higher level ontology. After this we might look for ways how to display the geometry in a browser ... there are several approached that could be taken for this.
Cheers
Lothar
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Champion and Mentors wanted for new potential Apache SST
incubator project
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Jun 11, 2021 at 6:39 AM Christofer Dutz <ch...@c-ware.de>
wrote:
> Hi Lothar,
>
> after a call with you and comparing that to the proposal, I think it
> would be great if you could explain a little bit more on a concrete
> example what SST does, which problem it solves and how it differs from
> existing solutions.
>
> For me at first the proposal was pretty lengthy but stayed so vague with
> WHAT it actually is, that this didn't trigger my interest at first.
> Perhaps being a little more concrete will help get some responses here.
>
> Chris
I had a bit of trouble understanding it as well, but from what I picked up
it sounds like an API and library to read and write industry-standard file
formats used in CAD/CAE/CAM systems, with ability to version control those
files or at least provide meaningful diffing of these formats.
STEP was mentioned several times. Not sure if that refers to the 3D file
format that's used as a data interchange between CAD systems, or is an
acronym for something else.
Should be interesting to hear more about it.
Cheers,
Nathan
Re: Champion and Mentors wanted for new potential Apache SST
incubator project
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Lothar,
after a call with you and comparing that to the proposal, I think it
would be great if you could explain a little bit more on a concrete
example what SST does, which problem it solves and how it differs from
existing solutions.
For me at first the proposal was pretty lengthy but stayed so vague with
WHAT it actually is, that this didn't trigger my interest at first.
Perhaps being a little more concrete will help get some responses here.
Chris
On 09.06.21 14:07, Lothar Klein wrote:
> Dear IPMC members,
>
> We are looking for a Champion and Mentors for the new SST incubator
> project proposal; see below.
> So far I contacted Justin Mclean and Christofer Dutz and they are
> considering to become mentors.
>
> Best Regards
> Lothar
>
>
> === Abstract ===
>
> SST (Semantic STEP Technology) is an optimized RDF/OWL API with
> GIT like revision control capabilities as an enabler for a new
> comprehensive CAD/CAx data model derived from ISO 10303 (STEP)
> and ISO 15926 (Oil & Gas) standards.
>
> === Rationale: The Problem to solve ===
>
> There are many different kinds of Computer-aided technology
> (CAx) systems around. Some are listed here:
> => https://en.wikipedia.org/wiki/Computer-aided_technologies
>
> For all organizations that are involved in the design,
> production, maintenance and commercial use of industrial
> products a smooth exchange of data between these tools would be
> needed. Also please have in mind that for most industrial
> production a big supply network has be coordinated; each with
> it’s own specific tools.
>
> The reality is that data exchange between these system is often
> not possible and if available the interface tools are
> incomplete as they exchange only some, but not all needed data.
> The problem get even worse as often the systems have to be used
> in a cyclic iterative way to deal with design changes. The
> truth is also that for all CAx systems a big part of the
> software development power (if not the biggest part) is spent
> on the interfaces to other system, not on the core
> functionality the system provides.
>
> STEP is a big attempt to address this issue. In the
> introduction of ISO 10303-1:1994 "Overview and fundamental
> principles" and extended in the 2021 edition we can read:
>
> "ISO 10303 is an International Standard for the
> computer-interpretable representation of product information
> and for the exchange of product data. The objective is to
> provide a neutral mechanism capable of describing products
> throughout their life cycle. This mechanism is suitable not
> only for neutral file exchange, but also as a basis for
> implementing and sharing product databases, and as a basis for
> archiving. The information generated about a product during its
> design, manufacture, use, maintenance, and disposal is used for
> many purposes. The use can involve many computer systems,
> including some that can be located in different organizations.
> In order to support such uses, organizations need to be able to
> represent their product information in a common
> computer-interpretable form that is required to remain complete
> and consistent when exchanged among different computer
> systems."
> => https://www.iso.org/obp/ui/#iso:std:iso:10303:-1:ed-2:v1:en
>
> In the introduction of ISO 15926-1:2004 "Overview and
> fundamental principles" we can see slightly different but
> highly overlapping goals:
> => https://www.iso.org/obp/ui/#iso:std:iso:15926:-1:ed-1:v1:en
>
> The goals of the ISO 10303 and 15926 series of standards are
> only very partially achieved in practice today.
>
> The aim of the SST project is to make the visions of these
> standards a reality by providing an open source environment
> that is suitable to directly operate on distributed data on servers
> managed by different organizations.
>
> === Background ===
>
> ISO 10303 and ISO 15926 and other series of standards are
> developed by the ISO Technical Committee 184: Automation
> Systems and Integration, Subcommittee 4: Industrial data. In
> its resolution number 9 from March 1985 the overall goal was
> expressed as: "To develop as soon as possible a single
> international standard for the exchange of product definition
> data to be called the standard for the exchange of product
> model data (STEP)." It took almost 10 years (1994/95) till the
> publication of the first set of standards. The geometric data
> models and assembly structures developed back then are today
> widely implemented by CAD and other systems. Since then the
> STEP standard grew constantly with lots of new application
> areas and layers of abstraction; but with only a few of the new
> capabilities really implemented and widely used. For upward
> compatibility reasons the originals data models where kept in
> place with only minor extensions.
>
> In parallel to the development of STEP, the process industry
> was searching for ways to capture the life-cycle data for their
> process plants. As ISO 10303 misses to capture the things
> around us in a clear and precise way they developed the ISO
> 15926 series of standards that are based on a 4D data model,
> allowing to fully capture things in time and space. The generic
> data model in part 2 was released in 2003, and now there is
> part 12 with a mapping to OWL:
> ISO/TS 15926-12:2018 Industrial automation systems and
> integration — Integration of life-cycle data for process plants
> including oil and gas production facilities — Part 12:
> Life-cycle integration ontology represented in Web Ontology
> Language (OWL)
>
> There had been a number of attempts to implement ISO 10303 and
> ISO 15926 on the basis of OWL/RDF technologies; but they all
> have in common that their performance is relatively low. This
> is on one hand caused by the way on how the data models are
> mapped to OWL, but are also caused by APIs such as Jena that
> are not optimized for this kind of data.
>
> === Proposal ===
>
> The Semantic STEP Technology (SST) establishes a novel way to
> operate with industrial product data as it is needed in
> CAD/CAM/CAx systems, part libraries, product live cycle system
> and similar product management systems. SST focuses to record
> and integrate all aspects of particular products such as
> machines, vehicles, buildings, electronics, piece parts in all
> their life cycle faces (e.g. requirements, design,
> manufacturing and planning, usage, maintenance, dismantling).
> Data is recorded and integrated in a computer sensible way so
> that computer systems can process the data and make decisions
> on what to do without direct human intervention. SST has a
> small memory footprint, allows fast traversing of application
> data in any direction and is implemented in the GO programming
> language. SST is optimized for web services and cloud
> computing, but is also suitable for traditional single user
> applications.
>
> The SST data models directly support data models that are
> defined in the ISO 10303 series of standards. ISO 10303 is
> widely known as STEP which stands for "STandard for the
> Exchange of Product model data". Unfortunately there are some
> disadvantages with STEP; primarily week semantic definitions,
> several modelling layers that are more or less replicating the
> lower layers in some modified way and widely overlapping
> Application Protocols (AP); resulting in a standard that is
> much more complex than it needs to be.
>
> To address the issue with week semantic definitions in STEP,
> the SST data model is founded on the 4D data model of ISO
> 15926, the standard for "Integration of life-cycle data for
> process plants including oil and gas production facilities".
> The 4D data model is a superior model to support all
> disciplines, supply chain company types and life cycle stages,
> regarding information about functional requirements, physical
> solutions, types of objects and individual objects as well as
> activities. However ISO 15926 misses the design specific
> aspects that STEP is focusing on to a big degree. A
> disadvantages of ISO 15926 is that it fully relies on class
> membership to state that several objects share common
> characteristics. This results in wide use of 2nd and 3rd degree
> higher level classes (named such as class_of_class_of_xxx) that
> are quite hard to follow and that are not very suitable for
> practical data exchange. SST replaces most of these higher
> level classes and relationships by modelling most application
> objects as individuals, including designs. Instead of using
> class membership, SST is using the "isDefinedBy" relationship
> to state that e.g. a physical individual is defined by a design
> individual (knowing that there are always some smaller or
> bigger deviations).
>
> For the implementation basis SST relies on the Semantic Web
> standards from W3C such as RDF RDFS and OWL. Basis is the
> mapping provided in part 12 of ISO 15926, "Life-cycle
> integration ontology represented in Web Ontology Language
> (OWL)". SST is using this mapping, but is adding additional
> constraints to support efficient implementations. So not every
> RDF data set is suitable to be managed by SST. The main
> constraints are:
> * every subject of a triple must have a base URI that is the
> same as the NamedGraph it is used in
> * splitting of data into NamedGraph for each application object
> that can be managed independently (e.g. a part of a part
> library, an organization, an assembly design)
> * NamedGraph have to import import other NamedGraphs for needed
> application objects by owl:imports (e.g. an assembly design
> imports parts)
> * NamedGraph are stored internally in a binary normalized
> (canonical) format that is optimized for very fast loading,
> saving, diff and merge operations
> * application data uses for the base URIs random UUID-URNs and
> also random UUIDs for the fragments
> * extensive use of punning, even for application data
> => https://www.w3.org/TR/owl2-new-features/#F12:_Punning
> * revision control is realized for Namespaces (a collection of
> NamedGraph), very similar to GIT
> * replication of Namespaces and history to other servers
> realized very similar to GIT
>
> === Initial Goals or the Mission ===
>
> To turn SST into an Apache top level project, the following
> features should be implemented for a 1.0 release:
> * Data Model adoptions to OWL and integration in SST-dictionary
> for early binding:
> -- ISO 15926-12
> -- STEP integrated resources for representation (part43),
> geometry & topology (part 42) and more
> -- core parts of the STEP AP242ed2 DO-model
> -- ISO 80000 Quantities and units
> -- formal SST schema with full constraints
> (similar to the capabilities Express but for OWL)
> * Internal data storage in binary form:
> -- NamedGraph
> -- Diff between two NamedGraph
> -- Complete/partial history of a NamedGraph
> (including several NamedGraphs and Diffs sections)
> -- Complete stage (all NamedGraph together)
> * CRUD API:
> -- late binding (references to resources are not checked)
> -- early binding (references to resources are checked through
> compiled dictionary)
> -- undo / redo since last commit
> * GIT like functionality:
> -- user identification, authorization, authentication;
> -- storage of Commit (user, timestamp, comment, Namespace
> with all involved NamedGraphs);
> -- storage of versions of NamedGraphs and Diffs under
> their checksum (SHA1 or SHA256);
> -- replication of Namespaces with history to other
> repositories (via packed file);
> -- delta update to/from remote repository
> * Tools:
> -- compiler to convert schema level ontologies into
> early binding applications
> -- schema level validation; e.g. using SHACL
> -- generic filtering and extraction, e.g. using SPARQL
> -- filling NoSQL DB with derived information for general
> searching
> * Import & Export:
> -- Turtle (*.ttl) files
> -- STEP part 21 files along AP242 (MIM level)
> for geometric models and assemblies
> -- STEP AP242 XML files for certain application areas
> * Applications:
> -- generic web-based viewer and editor to SST data
> -- generic STEP viewer for parts, assembly structures
> -- 3D viewer of already tessellated data
>
> === Current Status ===
>
> After many years of working in this field and trying out new
> approaches, the real implementation of this proposal in the GO
> programming language started from scratch in January 2021 by a
> core team of two persons.
>
> For end of June 2021 a full functional prototype is available
> consisting of the:
> * core API in late and early binding with complete CRUD
> functionality
> * binary RDF file handling for NamedGraphs and Diffs
> * import & export of Turtle files (*.ttl)
> * STEP AP242 XML import
> * a generic Web-Viewer onto the data
> * and more is available
>
> These capabilities are sufficient to start with the
> implementation of first SST applications.
>
> Next major things to implement are generic query capabilities
> (SPARQL), testing for schema level conformance (e.g. SHACL),
> GIT like functionalities for merging and replication, NoSQL DB
> adoption for querying derived information.
>
> ** Meritocracy **
> So far the SST project grew up in the non public by two
> persons; each having a different focus. It is clear that this
> phase is ending when SST is turned into an Apache incubator
> project.
>
> There are many potential SST extensions and application areas
> inside and outside of the ASF that can only be managed by a
> real community.
>
> ** Community **
> In the early days of STEP many universities, research
> institutes and CAD related companies where involved in the
> development and implementation of the STEP standard. This is
> partly documented in the book "The Grand Experience" from
> Sharon J. Kemmerer, NIST, 1999. But as the implementations got
> more mature, the strong growth in complexity of the standard
> and the endless time needed to get consensus and run through
> the standardization process, the number of participants got
> smaller and smaller.
>
> Today, as most of the original planned capabilities had been
> finally standardized, and there is a new way to implement STEP
> using RDF/OWL on the basis of a major parts of ISO/TS 15926-12,
> there is a good chance that a new community will come together;
> especially as today the integration of all these data on the
> Internet is so much demanded.
> There are already several communities around for which SST may
> play a role, e.g.:
> * MBx / CAx-IF implementor forum
> => https://www.cax-if.org/index.php
> * LOTAR, Long Term Archiving and Retrieval
> => https://lotar-international.org/
> * POSC Caesar Association
> => https://www.posccaesar.org/
>
> ** Core Developers **
> The core developers are Vaidas Nargelas for the central GO code
> and Lothar Klein for the STEP data model and converter.
>
> ** Alignment **
> Other than standard GO libraries, SST is not really dependent
> on other packages. However SST requires a second NoSQL DB with
> derived information for which one of the Apache projects might
> be used (maybe Apache Solr). Also it is clear that SST cloud
> applications (e.g. micro services) will require several of the
> capabilities provided by Apache.
> For some potential SST applications a linkage via Apache PLC4X
> might be used to directly drive production lines or a single NC
> machine from data stored in SST.
>
> ** Known Risk **
> Failure to set up a developer community
>
> ** Project Name **
> We think that "Semantic STEP" is an appropriate naming of the
> project as it clearly links with the W3C "Semantic Web"
> standards and is clearly indicating the application area
> "STEP".
>
> Within the code we widely use the prefix to indicate the GO
> packages:
> * sst for the core API
> * ssowl for the OWL ontology
> * sslci for the adopted life-cycle ontology from ISO 15926
> * ssont for the adopted STEP ontology
> * ssrep for the adopted STEP representation models
> (e.g. geometry & topology)
> * etc.
>
> There are no trademarks on "Semantic STEP", however there are
> several trademarks for "SST". But as these letters are so
> generic there should be no conflict when using "Apache SST".
>
> Also there are several web-domains registered such as:
> * semantic-step.net and semanticstep.net
> * semantic-step.org and semanticstep.org
>
> The sponsoring entity is ready to transfer these domains to ASF
> is this proposal is accepted
>
> ** Orphaned products **
> Both, Lothar Klein (Germany) and Vaidas Nargelas (Lithuania)
> have a long term commitment to make SST a success.
>
> ** Inexperience with Open Source **
> Back in 2013 the committers have already released JSDAI under
> the AGPL v3 license (see www.jsdai.net). "J" stands for Java
> and "SDAI" stands for the "Standard Data Access Interface";
> primarily an API according to:
>
> ISO/TS 10303-27:2000 Industrial automation systems and
> integration — Product data representation and exchange
> — Part 27: Implementation methods: Java TM programming
> language binding to the standard data access interface
> with Internet/Intranet extensions
> => https://sourceforge.net/projects/jsdai/
> => https://jsdai.net/
>
> ** Length of Incubation **
> maybe 6 to 12 month till the point that an initial community
> has formed and a first release with all core components is
> available.
>
> ** Homogenous Developers **
> The two initial founders of SST have quite different focuses
> and experiences.
> It is clear that during the incubation time the focus must be
> to build up a community. As the proposers have various contacts
> to universities and industry around the world this should be
> feasible over some time.
> However there is the chicken-egg problem. So first SST needs to
> become an official Apache incubator project to make people
> interested and ensure them that this is real opens software
> with an open community.
>
> ** Reliance on Salaried Developers **
> So far the SST development is sponsored by LKSoftWare GmbH and
> the expectations is that this continues.
>
> ** Relationship with Other Apache Products **
> Currently there are no dependencies on other ASF projects but
> Apache Solr and Apache Cassandra are being considered.
>
> ** A Excessive Fascination with the Apache Brand **
> So far SST was developed without considering to make it an ASF
> project. Weighting the pros and cons we come to the conclusion
> that as an ASF project SST has a much bigger chance to make it
> a success; especially because only in this case we can hope
> that SST is widely used to publish industrial product data in a
> computer sensible way on the Internet.
>
> ** Documentation **
> Not ready today. More detailed SST documentation will become
> available when in incubator stage.
>
> ** Initial Source **
> All source files (GO, Turtle) are currently stored in an
> internal GIT of LKSoftWare GmbH.
> Source and Intellectual Property Submission Plan
> All is currently under copyright of LKSoftWare GmbH.
> Will be moved over to ASF when this podling application is
> successful.
>
> ** External Dependencies **
> No
>
> ** Cryptography **
> There is no cryptography involved in the core code-base.
>
> === Required Resources ===
> ** Mailing lists: **
> Needed lists are private@..., dev@..., commits@...
>
> ** Subversion Directory **
> No
>
> ** Git Repositories **
> Yes
>
> ** Issue Tracking **
> JIRA
>
> ** Other Resources **
> A Wiki for the documentation
>
> ** Initial Committers **
> Vaidas Nargelas <va...@gmail.com>
> Lothar Klein <lo...@lksoft.com>
>
> === Sponsors ===
> ** Champion: **
> TBD
>
> ** Nominated Mentors: **
> TBD
>
> ** Sponsoring Entity: **
> TBD
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>