[{"content":"\rNews\r#\r2026-04-27: SST-Core v1.0.0 is released and available under either a commercial license or under the POLYFORM Noncommercial 1.0.0 license. The sources are available on https://github.com/semanticstep/sst-core ; see News\nOverview\r#\rSemantic STEP Technology (SST) is a tool for the development of web services and other applications that focuses on all kinds of industrial products data, including the design, production, maintenance and use of these products. All application data in SST is stored internally using Semantic Web technology as defined by W3C. Because of this SST-Data is always available in full detail to the creators of this data and ready to be shared with others on the Internet.\nSST-EDM, Engineering Data Management, is a first web application for industrial user that is using the underlying SST-Core capabilities. The focus is on CAD, CAM, ERP, PDM related data. Breakdown structures on the basis of IEC 81346 Reference Data Systems (RDS) is the first supported application area. Electrical Wire Harnesses design is currently under development and this will directly support data exchange on the basis of STEP AP242 (ISO 10303-242:2025). Other application areas to follow.\nSST Data Modelling Parts / Open Data\r#\rThe foundation of the SST/EDM ontologies (data modelling) is the unique combination of three series of standards:\nSemantic Web technologies: RDF/S, XSD, OWL, \u0026hellip; ISO 15926 for the \u0026ldquo;Integration of life-cycle data for process plants, including oil and gas production facilities\u0026rdquo; ISO 10303, STEP, the standards for industrial product data that is widely supported by CAD systems, with a focus on STEP AP242 Other major data modelling parts are added to cover:\nISO 8000 for the Quantities and Units as the basis to define all kinds of properties\nDictionary data as defined in\nISO 13584 Part Library\nIEC 61360 Common Data Dictionary\nISO 13399 Cutting Tools\neClass\nIEC 81346 Reference Designation Systems\nSir Tim Berners-Lee the inventor of the World Wide Web and founder of the World Wide Web Consortium (W3C) says: \u0026ldquo;The Semantic Web is an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in cooperation\u0026rdquo; . Basis for any kind of data in the Semantic Web is RDF, the Resource Description Framework, that breaks down each piece of information into statements, consisting of a subject, a predicate and an object, called triples. The basis of the well-defined meaning is given by OWL, the Web Ontology Language that is defined on a mathematical basis. And for the exchange of RDF data there is Turtle (*.ttl files) and JSON-LD (JSON Linked Data) that works efficiently for Web-browsers. Together these Semantic Web standards define the foundation of SST.\nSTEP on the other hand is an International Standard for the computer-interpretable representation of product information with the objective to \u0026ldquo;provide a neutral mechanism capable of describing products throughout their life cycle\u0026rdquo; in a way that is suitable for data exchange, data integration and archiving. While STEP is very powerful and successful in some areas (e.g. 3D models) it is less successful in other areas (e.g. PLM - product lifecycle management, PDM - product data management). A reason is the week semantic basis of some core concepts of STEP that requires the generation of non useful data and that makes it difficult to use together with OWL.\nISO 15926 was developed by the same ISO technical subcommittee as STEP (ISO TC184/SC4) and was originally planned as a potential successor of STEP. It defines a very systematically basic structure for all things around us, together with a rather effective 4D concept to document the changes of things in space and time. Part 12 of ISO 15926 defines a rather effective mapping of these concepts into OWL. A disadvantage of ISO 15926 is that it also defines several highly abstract concepts (e.g. a class_of_class_of_class) whose practical usefulness is questionable.\nSST is the combination of these three series of standards in the following way:\nOWL is originally defined to support logical reasoning (also called inferencing) on the underlying RDF data; but this reasoning can take a lot of time and memory. SST is not relying on reasoning; instead it requires to explicitly state the basis information needed to directly take advantage of the provided data. This works in combination with the SST API (see below).\nOnly the very basic concepts, about half of ISO 15926-12, are used for SST. Other higher level concepts are replaced by more simple and directly usable concept, and that better fit with STEP\nAll STEP parts on representation such as geometry, topology, kinematics etc. are directly, or with only minimal changes adopted from SST. Other parts of STEP, primarily in the product data management (PDM) and product lifecycle management (PLM) area replaced by ISO 15926 concepts, or concepts derived from this.\nIn addition SST has defined new ontologies for:\nISO 80000 series of standard on Quantities and Units to be able to support any quantity and unit define there. This was needed as other known models in this area have significant disadvantages\nISO/IEC 81346 series of standards on Reference Designation Systems (RDS)\nand contains direct support of Dictionaries to be used for Part Libraries that are based on ISO 13584 such as:\nIEC 61360 Common Data Dictionary\neClass\nISO 13399 Cutting tool data representation and exchange\nISO 13584-511 Mechanical systems and components for general use — Reference dictionary for fasteners\nSST Implementation Parts / Commercial\r#\rThe SST commercial implementations directly take advantage of the Open Source data representation structure as defined above. There are\nSST API : Application programming interface with the combination of the following unique features: ** completely written in GO programming language; the most efficient way for web applications ** late and early binding support. With early binding for each ontology concept a direct GO constructs are available; generated by the SST Compiler. This makes application programming straight forward ** triplex structure for being able to traverse an RDF graph that consists of triples in any direction\nSST Repository ; either remote or local for the persistent storage of RDF data, grouped into NamedGraphs and Datasets. A remote SST Repository is the default way for SST to publish data on the web\nGIT like revision control capabilities to enable collaborative work on RDF data. GIT is very widely used system for software development, that provides a database for source code with strict revision control capabilities for each piece of source code. This includes commits, splitting the sources into branches and independent development, but being able to merge them afterwards. SST is providing the same kind of capabilities for NamedGraphs that define a set of triples (typically contained in an RDF file)\nSST- EDM : Engineering Data Management; a web application that is currently under development and whose services are realised by SST. EDM is intended to take advantage of many capabilities of SST, but it is clear that many more customer specific applications will be needed to serve specific purposes.\n","externalUrl":null,"permalink":"/","section":"About SST \u0026 EDM","summary":"","title":"About SST \u0026 EDM","type":"page"},{"content":"This web site is powered by Hugo \u0026amp; Blowfish\n","externalUrl":null,"permalink":"/footer/attribution/","section":"Footers","summary":"","title":"Attribution","type":"footer"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"RDS TBD\n","externalUrl":null,"permalink":"/edm/breakdown/","section":"SST-EDM Overwiew","summary":"","title":"Breakdown / Reference Designation System (RDS)","type":"edm"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"ClassSystem TBD\n","externalUrl":null,"permalink":"/edm/class_system/","section":"SST-EDM Overwiew","summary":"","title":"Class Systems \u0026 Properties","type":"edm"},{"content":"You should become familiar with the following core concepts and terms before attempting to develop your own application using the SST Core API:\nprogramming languages : The SST Core is fully implemented in the GO programming language; so this is what you should use to take full advantage of the provided functionality. Programming for the web-browser with JavaScript /TypeScript is possible using the standard or the SST customised version of JSON-LD; but this is restricted on receiving (reading) and sending (committing) NamedGraphs\nSemantic Web: a set of standard recommendations of the World Wide Web Consortium (W3C) to make data on the Internet machine-readable. Major parts of the Semantic Web supported by SST are:\nRDF: Resource Description Framework RDFS: Resource Description Framework Schema OWL: Web Ontology Language Turtle: Terse RDF Triple Language IRI (URI , URN , URL) and RDF : Internationalized Resource Identifiers (IRI) are the basis of the Resource Description Framework (RDF) that are needed to represent Triples . IRIs are an extension of Uniform Resource Identifiers (URI) supporting international characters (Unicode). The majority of URIs used by SST are Uniform Resource Locator (URL) and Uniform Resource Names (URN).\nUUID : Universally unique identifiers are widely used throughout SST. Primarily SST is using random UUID (variant 4) to ensure that no one else is creating unintentionally the same UUID. In a few special cases SST is also using the \u0026ldquo;namespace name-based\u0026rdquo; (version 5) when a hash value of some data is needed.\nUUID URN : By default SST is generating a random UUID-URN to identify a newly created pair of a Dataset and it\u0026rsquo;s default NamedGraph. Example: urn:uuid:8D8AC610-566D-4EF0-9C22-186B2A5ED793. But SST also fully supports the use of other IRIs such as URLs to identify such pairs.URLs are e.g. used to identify the higher level ontologies used by SST.\nUUID Fragment: By default SST is generating random UUID for the IRI fragments of IBNodes within a `NamedGraph\u0026rsquo;; however every other valid fragment is supported as well.\nHash : This is a binary SHA256 value that is used to uniquely identify either a DatasetRevision , a NamedGraphRevision or a Commit\nGIT : \u0026ldquo;Git is a distributed version control system that tracks versions of files. It is often used to control source code by programmers who are developing software collaboratively\u0026rdquo;. SST inherits major concepts from GIT, but adopt them to RDF data instead of programming code. So in a similar way we can say that \u0026ldquo;SST is a distributed version control system that tracks versions of RDF data. It\u0026rsquo;s purpose is to control RDF data in a collaborative way. \u0026quot;\nRepository : The place to store persistently RDF Datasets. A Remote Repository is an application in it\u0026rsquo;s own whose access is controlled by the OAUTH2 protocol. Otherwise the repositories are stored within the local file system and it is up to the application that uses the SST Core to decide about if there is any access control and how to realise this. A full featured Repository in SST comes with GIT like revision control of the contained data, query capabilities, and transaction control; simple repository types don\u0026rsquo;t have this.\nDataset : The main content of a Repository are Datasets as defined in RDF; consisting of a default graph and other NamedGraphs . For SST also the default graph is a NamedGraph , and it\u0026rsquo;s IRI is the same as the one of the corresponding Dataset for which it is the default one. For SST the \u0026ldquo;other\u0026rdquo; NamedGraphs of a Dataset are explicitly imported in SST by owl:imports. For the SST API this is addressed by a special Import functionality of NamedGraph\nDatasetRevision : A particular revision of a Dataset consisting of a default NamedGraphRevision and all other NamedGraphRevision that are either directly or indirectly imported into the default NamedGraphRevision. A DatasetRevision is identified by a Hash value\nNamedGraph : RDF graph that is defined as a set of RDF triples and that is identified by an IRI (without a fragment), In a Repository with revision history support, several revisions of the same NamedGraph can exist. In a Stage only one particular revision of a NamedGraph can exist at a time. The NamedGraphs in a Stage are either local , meaning that all their triples are in memory as well, or they are in referenced state, meaning that the triples are not in memory. Expectation is that referenced NamedGraphs can be turned into local NamedGraph somehow, e.g. by loading the triples from some repository or by reading an RDF file. By default the triples in a local NamedGraph in a Stage can be modified and saved; e.g. by Commit into a Repository or written out into an RDF or SST file\nNamedGraphRevision: A particular version of a NamedGraph in a Repository, identified by a Hash value.\nStage: The place in memory where NamedGraphs are opened, created, modified or deleted. When a Stage is closed, all the NamedGraph objects in it become invalid. An SST application typically opens at least one Stage, but may use several in parallel. NamedGraphs can be either copied or moved from one Stage into another one. A Stage might be linked to a Repository to make the NamedGraph s in it persistent.\nCommit : The operation to write modified NamedGraph s in a Stage into the linked Repository of this Stage. During Commit for each\na new NamedGraph and a new Dataset entry for each new NamedGraph in the Stage a new NamedGraphRevision and a new DatasetRevision for each new or modified NamedGraph in the Stage and in addition a new DatasetRevision for each NamedGraph in the Stage that is not new or modified, but that imports directly or indirectly other modified NamedGraphs Triple : A statement consisting of a subject node, a predicate node and either an object node or a literal. For SST the subject node is owned by the NamedGraph in which the triple is defined.\nIBNode : Using RDF terms, an IBNode is either an IRI node, a blank node or a collection (here ObjectCollection ). Note that the optimised LiteralCollections are not treated as IBNodes .\nIRI node : For SST, an IRI node is composed by the base IRI used for it\u0026rsquo;s NamedGraph followed by the \u0026ldquo;#\u0026rdquo; symbol\u0026rdquo; and a fragment. By default the fragment of a newly created IRI node is a random UUID . Blank node : An RDF blank node that is \u0026ldquo;owned\u0026rdquo; by a NamedGraph in which it is defined. BlankNodes in one NamedGraph can not be referenced from outside the NamedGraph in which they are defined. Internally in SST a blank node is identified by a \u0026ldquo;namespace name-based\u0026rdquo; (version 5) UUID Literal :\nObjectCollection : An RDF collection that is an ordered list of RDF nodes or literals. An ObjectCollection can also contain other ObjectCollections as elements.\nLiteralCollection : a special optimised RDF collection type where all items must be of the same literal type and that can only be used as Object in a triple. LiteralCollections can not be shared as Objects for several triples.\nTriplex structure : A special data structure in memory to represent all the triples of the NamedGraphs in a Stage. The structure is optimised to allow fast traversing an RDF graph in any direction:\nUni-Directional: here only the forward direction of triples is available; starting from a subject to predicates and objects; this is common for most tools Bi-Directional: here in addition the reverse direction of triples is available; starting from an object node to predicates and subjects; a number of tools can support this only by a query operation Tri-Directional: here in addition a middle direction of triples is available; starting from a predicate to subjects and objects. This has special importance as SST is widely using \u0026ldquo;punning\u0026rdquo; in the sense that a node can be both a property and an individual TBD RDF / Turtle file: W3C defines several kinds/formats of RDF files. For the time being the only RDF format supported by SST is Turtle; typically with the file extension *.ttl. SST restricts Turtle files to contain exactly one NamedGraph with all triples having subjects that are either IRI nodes with the same bases IRI as this NamedGraph or are blank nodes or ObjectCollections of this NamedGraph.\nSST-File: An SST specific binary RDF file format that is highly optimised for speed. This file format is also used as storage format inside an SST Repository and for the communication between an SST client and a remote SST Repository\nOAUTH2 : remote SST Repositories use the OAUTH2 protocol to verify the access rights of an application/client to access the content of the repository.\nOIDC : Open ID Connect\ngRPC: SST is using the Google Remote Procedure Call framework for the communication between an SST Client and a remote SST Repository\n","externalUrl":null,"permalink":"/sst_core/terms/","section":"SST Core","summary":"","title":"Core concepts and terms","type":"sst_core"},{"content":"You might use an IDE (Integrated Development Environment) such as VSC (Visual Studio Code) to develop an SST application.\nLet\u0026rsquo;s create Hello World Write example to generate some RDF data.\nGolang IDEs such as VSC manages the needed imports automatically; so user don\u0026rsquo;t need worry about these. However there is one exception with \u0026ldquo;git.semanticstep.net/x/sst/vocabularies/dict\u0026rdquo;. This package contains essential initialisation code for the default vocabularies/dictionaries used by SST. To enforce proper initialisation of this package it has to be entered manually with a leading _ that will prevent that this manually enterned import is not taken away as it is not referenced in the code. So for this example we\u0026rsquo;ll get at the end these imports:\npackage main\rimport (\r\u0026quot;fmt\u0026quot;\r\u0026quot;log\u0026quot;\r\u0026quot;os\u0026quot;\r\u0026quot;git.semanticstep.net/x/sst/sst\u0026quot;\r_ \u0026quot;git.semanticstep.net/x/sst/vocabularies/dict\u0026quot;\r\u0026quot;git.semanticstep.net/x/sst/vocabularies/lci\u0026quot;\r\u0026quot;git.semanticstep.net/x/sst/vocabularies/rdfs\u0026quot;\r\u0026quot;github.com/google/uuid\u0026quot;\r)\rThe first thing in an SST application is to create a stage in which we are going to create the nodes and triples. For this example we are using a new empty ephemeral stage that is not bound to any existing [Repository] and [Dataset]; so the data we are going to create can not directly be committed into a SST Repository.\nfunc main() {\rfmt.Println(\u0026quot;HelloWorldWrite ... \u0026quot;)\rstage := sst.OpenStage(sst.DefaultTriplexMode)\rA stage contains NamedGraphs where one NamedGraph may import other NamedGraph, forming a directed acyclic graphs of NamedGraphs. Let\u0026rsquo;s create a new single NamedGraph that is identified by a random UUID-URN (version 4).\ngraph := stage.CreateNamedGraphByUUID(uuid.New())\rfmt.Println(\u0026quot;URI of NamedGraph = \u0026quot; + graph.IRI())\rThe resulting NamedGraph might e.g. have the URI urn:uuid:a8f3dc19-68f5-44d1-97bc-21ba2d8a6037\nib := graph.CreateIRINode(uuid.New().String(), lci.Individual)\rfmt.Println(\u0026quot;IRI of IRI node = \u0026quot; + ib.IRI())\rfmt.Println(\u0026quot;Fragment of IRI node = \u0026quot; + ib.Fragment())\rNext we create a new IRI node in the NamedGraph together with a first triple to specifiy it\u0026rsquo;s rdf:type.\nIn this case the node is identified by a fragment that contains a random-UUID within the NamedGraph. E.g. the UUID of the fragment is 6d52b623-f933-4c26-ba18-164a6cc50ae8, and so the complete IRI of the node is e.g. urn:uuid:a8f3dc19-68f5-44d1-97bc-21ba2d8a6037#6d52b623-f933-4c26-ba18-164a6cc50ae8. Note that this IRI contains 2 different UUIDs, one for the NamedGraph, and one for the fragment of the node in that NamedGraph. An IBNode can exist in a NamedGraph only when it has at least one subject triple; so here we say it has the type lci.Individual.\nib := graph.CreateIRINode(uuid.New().String(), lci.Individual)\rwith AddStatement we can add further triples\nib.AddStatement(rdfs.Label, sst.String(\u0026quot;HelloWorld\u0026quot;))\r// Next we create a triple (s statement) with:\r// * subject: the IRI node we created\r// * predicate: rdf:type\r// * object : an lci:individual, that is a concept of the life-cycle integration ontology on which SST is based on.\r// the created graph can be exported into a Turtle (*.ttl) file that has a readable text representation\rf, err := os.Create(\u0026quot;helloworldwrite.ttl\u0026quot;)\rif err != nil {\rpanic(err)\r}\rdefer f.Close()\rerr = graph.RdfWrite(f, sst.RdfFormatTurtle)\rif err != nil {\rlog.Panic(err)\r}\r// alternatively the created graph can be exported into a binary SST file that is much faster to process compared to turtle.\r// for this we first create a file ...\rout, err := os.Create(\u0026quot;helloworldwrite.sst\u0026quot;)\rif err != nil {\rlog.Panic(err)\r}\r// ... ensure that the file will be closed at the end ...\rdefer func() {\r_ = out.Close()\r}()\r// ... and write the binary graph content out into the file.\rerr = graph.SstWrite(out)\rif err != nil {\rlog.Panic(err)\r}\rfmt.Printf(\u0026quot;Done\\n\u0026quot;)\r}\n","externalUrl":null,"permalink":"/sst_core/hellowrite/","section":"SST Core","summary":"","title":"Example: HelloWorldWrite.go","type":"sst_core"},{"content":"","externalUrl":null,"permalink":"/footer/","section":"Footers","summary":"","title":"Footers","type":"footer"},{"content":"The core data model of SST is based on: ISO 15926-2:2003 Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilitiesPart 2: Data model\nThis data model got mapped onto OWL by: ISO/TS 15926-12:2018 Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilitiesPart 12: Life-cycle integration ontology represented in Web Ontology Language (OWL)\nThe Live-Cycle Integration (LCI) ontology of ISO/TS 15926-12 had been the basis for the development of the SST-LCI ontology. As the ISO/TS 15926-12 ontology does not cover all capabilities of ISO 10303-2 and does not contain all the details and explanations, this pages provides a mapping from the ISO/TS 15926-12 data model to the SST-LCI ontology.\nMapping\r#\rISO 15926-2 entity types:\ncx: class of various levels; c1: level 1 class; e.g. individual c2: level 2 class; e.g. class of individual c3: level 3 class; e.g. class of class of individual c3r: level 3 class of relationships cx-cx: relationship if arbitrary domain and range level c1-c1: Relationsip with both domain and range at level c1 ISO 15926-2 type ISO/TS 15926-12 SST-LCI SST-LCI Status Comment 5.2.1 Things 5.2.1.1 abstract_object cx lci:AbstractObject lci:AbstractObject 5.2.1.2 thing cx lci:Thing lci:Thing OK Abstract, 5.2.2 Classes 5.2.2.1 class c2 lci:Class lci:Class TBC 5.2.2.2 class_of_abstract_object c2 lci:ClassOfAbstractObject lci:ClassOfAbstractObject OK 5.2.2.3 classification c1-c1 rdf:type rdf:type OK same as \u0026quot; a \u0026quot; in Turtle 5.2.2.4 specialization c1-c1 rdfs:subClassOf rdfs:subClassOf OK arrow with triangle in UMLet, In Express a thick line 5.2.3 Classes of class 5.2.3.1 class_of_class c3 lci:ClassOfClass lci:ClassOfClass TBC 5.2.3.2 class_of_classification N 5.2.3.3 class_of_property_space c3 N 5.2.3.4 class_of_specialization N 5.2.4 Multidimensional objects 5.2.4.1 class_of_multidimensional_object cx lci:ClassOfList lci:ClassOfList No 5.2.4.2 multidimensional_object lci:List lci:List TBC 5.2.5 Numbers 5.2.5.1 arithmetic_number c3 lci:Number lci:Number TBC 5.2.5.2 boundary_of_number_space N 5.2.5.3 class_of_number c3 N 5.2.5.4 enumerated_number_set N 5.2.5.5 integer_number c3 lci:Integer lci:Integer TBC 5.2.5.6 lower_bound_of_number_range lci:numberRangeHasLowerBound lci:numberRangeHasLowerBound TBC 5.2.5.7 multidimensional_number c3 N 5.2.5.8 multidimensional_number_space c3 N 5.2.5.9 number_range c3 lci:NumberRange lci:NumberRange TBC 5.2.5.10 number_space c3 lci:NumberSpace lci:NumberSpace TBC 5.2.5.11 real_number c3 lci:Real lci:Real TBC 5.2.5.12 upper_bound_of_number_range lci:numberRangeHasLowerBound lci:numberRangeHasLowerBound TBC 5.2.6 Possible individuals c1 5.2.6.1 actual_individual c1 lci:ActualIndividual lci:ActualIndividual OK see also lci:Non-actualIndividual 5.2.6.2 arranged_individual c1 lci:ArrangedIndividual lci:ArrangedIndividual OK see also lci:Non-arrangedIndividual 5.2.6.3 arrangement_of_individual c1 lci:arrangedPartOf / lci:hasArrangedPart lci:arrangedPartOf / lci:hasArrangedPart OK 5.2.6.4 assembly_of_individual lci:assembledPartOf / lci:hasAssembledPart lci:assembledPartOf / lci:hasAssembledPart OK 5.2.6.5 composition_of_individual c1-c1 lci:partOf / lci:hasPart lci:partOf / lci:hasPart OK 5.2.6.6 feature_whole_part lci:featureOf / lci:hasFeature lci:featureOf / lci:hasFeature OK 5.2.6.7 functional_physical_object c1 lci:FunctionalPhysicalObject lci:FunctionalPhysicalObject OK 5.2.6.8 materialized_physical_object c1 lci:MaterializedPhysicalObject lci:MaterializedPhysicalObject OK 5.2.6.9 period_in_time c1 lci:PeriodInTime lci:PeriodInTime OK 5.2.6.10 physical_object c1 lci:PhysicalObject lci:PhysicalObject OK 5.2.6.11 possible_individual c1 lci:Individual lci:Individual OK see new basic subtypes lci:SpaceTimeIndividual and lci:OtherIndividual 5.2.6.12 spatial_location c1 lci:PointInSpace lci:PointInSpace / lci:RegionInSpace OK 5.2.6.13 stream c1 lci:Stream lci:Stream TBC isn\u0026rsquo;t stream a kind of activity? 5.2.6.14 temporal_whole_part lci:temporalPartOf lci:temporalPartOf / lci:hasTemporalPart OK 5.2.6.15 whole_life_individual c1 lci:WholeLifeIndividual lci:WholeLifeIndividual OK see also lci:Non-wholeLifeIndividual 5.2.7 Classes of individual 5.2.7.1 class_of_arrangement_of_individual N No not needed for SST 5.2.7.2 class_of_assembly_of_individual N 5.2.7.3 class_of_class_of_composition c3r N No not needed SST 5.2.7.4 class_of_class_of_individual c3 lci:ClassOfClassOfIndividual lci:ClassOfClassOfIndividual TBC 5.2.7.5 class_of_composition_of_individual TBC * lci:valuePartOfOccurrence / lci:classHasPartValue lci:valuePartOfOccurrence / lci:classHasPartValue * lci:classPartOfOccurrence / lci:classHasPartOccurrence lci:classPartOfOccurrence / lci:classHasPartOccurrence 5.2.7.6 class_of_event c2 lci:ClassOfEvent lci:ClassOfEvent TBC 5.2.7.7 class_of_feature_whole_part N 5.2.7.8 class_of_individual c2 lci:ClassOfIndividual lci:ClassOfIndividual TBC 5.2.7.9 class_of_period_in_time c2 lci:ClassOfPeriodInTime lci:ClassOfPeriodInTime No not needed for SST 5.2.7.10 class_of_point_in_time c2 lci:ClassOfPointInTime lci:ClassOfPointInTime No not needed for SST 5.2.7.11 class_of_status c3 lci:ClassOfStatus lci:ClassOfStatus OK 5.2.7.12 class_of_temporal_whole_part TBC * lci:valueTemporalPartOfOccurrence / lci:classHasTemporalPartValue lci:valueTemporalPartOfOccurrence / lci:classHasTemporalPartValue * lci:classTemporalPartOfOccurrence / lci:classHasTemporalPartOccurrence lci:classTemporalPartOfOccurrence / lci:classHasTemporalPartOccurrence 5.2.7.13 status c2 lci:Status lci:Status TBC 5.2.8 Classes of arranged individual 5.2.8.1 class_of_arranged_individual c2 lci:ClassOfArrangedIndividual use c1 lci:ArrangedIndividual, no subtypes 5.2.8.2 class_of_atom c2 lci:ClassOfAtom c1 lci:ChemicalElement OK different level 5.2.8.3 class_of_biological_matter c2 lci:ClassOfBiologicalMatter c1 lci:BiologicalMatter OK at lower level 5.2.8.4 class_of_composite_material c2 lci:ClassOfCompositeMaterial c1 lci:CompositeMaterial OK at lower level 5.2.8.5 class_of_compound c2 lci:ClassOfCompound c1 lci:Compound OK at lower level 5.2.8.6 class_of_feature c2 lci:ClassOfFeature c1 lci:Feature OK at lower level 5.2.8.7 class_of_functional_object c2 lci:ClassOfPhysicalObjectByFunction c1 lci:ClassOfPhysicalObjectByFunction TBC needed for IEC81346 classes? 5.2.8.8 class_of_inanimate_physical_object c2 lci:InanimatePhysicalObject c1 lci:InanimateIndividual OK at lower level, see also lci:AnimateIndividual 5.2.8.9 class_of_information_object c2 lci:ClassOfInformationObject c1 lci:InformationObject OK at lower level 5.2.8.10 class_of_information_presentation c2 lci:PhysicalRepresentationType c1 lci:PhysicalRepresentationType TBC 5.2.8.11 class_of_molecule c2 lci:ClassOfMolecule c1 lci:ChemicalCompount OK at lower level 5.2.8.12 class_of_organism c2 lci:ClassOfOrganism c1 lci:Organism OK at lower level 5.2.8.13 class_of_organization c2 lci:ClassOfOrganization c1 lci:Organization OK at lower level 5.2.8.14 class_of_particulate_material c2 lci:ClassOfParticulateMaterial c1 lci:ParticulateMaterial OK at lower level 5.2.8.15 class_of_person c2 lci:ClassOfPerson c1 lci:Personat lower level 5.2.8.16 class_of_sub_atomic_particle c2 c1 lci:SubAtomicParticle OK at lower level 5.2.8.17 crystalline_structure c2 lci:CrystallineStructure c1 lci:CrystallineStructure OK at lower level 5.2.8.18 phase c2 lci:Phase c1 lci:MatterPhase OK at lower level, split into main phase types 5.2.9 Activities and events 5.2.9.1 activity c1 lci:Activity lci:Activity OK 5.2.9.2 beginning lci:begins / lci:hasBeginning lci:begins / lci:hasBeginning OK 5.2.9.3 cause_of_event c1-c1 lci:causes / lci:hasCause lci:causes / lci:hasCause OK 5.2.9.4 ending lci:ends / lci:hasEnd lci:ends / lci:hasEnd OK 5.2.9.5 event c1 lci:Event lci:Event OK no subtype point_in_time 5.2.9.6 involvement_by_reference cx-c1 lci:referencedBy / lci:references lci:referencedBy / lci:references 5.2.9.7 participation lci:participantIn / lci:hasParticipant lci:participantIn / lci:hasParticipant OK misses specializations such as input/output/resource 5.2.9.8 point_in_time c1 lci:PointInTime lci:PointInTime OK 5.2.9.9 recognition cx-c1 N lci:Recognition ? TBC requires punning, but how? 5.2.9.10 temporal_bounding lci:temporalBoundOf / lci:hasTemporalBound lci:temporalBoundOf / lci:hasTemporalBound OK abstract 5.2.10 Classes of activity 5.2.10.1 class_of_activity c2 lci:ClassOfActivity c1 lci:Activity NO covered by lci:Activity 5.2.10.2 class_of_cause_of_beginning_of_class_of_individual TBC * lci:causesBeginningOf / lci:hasCauseOfBeginning lci:causesBeginningOf / lci:hasCauseOfBeginning * lci:classHasCauseOfBeginningOccurrence / lci:classCausesBeginningOfOccurrence lci:classHasCauseOfBeginningOccurrence / lci:classCausesBeginningOfOccurrence * lci:classHasCauseOfBeginningValue / lci:valueCausesBeginningOfOccurrence lci:classHasCauseOfBeginningValue / lci:valueCausesBeginningOfOccurrence * lci:classCausesBeginningOfValue / lci:valueHasCauseOfBeginningOccurrence lci:classCausesBeginningOfValue / lci:valueHasCauseOfBeginningOccurrence 5.2.10.3 class_of_cause_of_ending_of_class_of_individual TBC * lci:causesEndOf / lci:hasCauseOfEnd lci:causesEndOf / lci:hasCauseOfEnd * lci:classHasCauseOfEndOccurrence / lci:classCausesEndOfOccurrence lci:classHasCauseOfEndOccurrence / lci:classCausesEndOfOccurrence * lci:classHasCauseOfEndValue / lci:valueCausesEndOfOccurrence lci:classHasCauseOfEndValue / lci:valueCausesEndOfOccurrence * lci:classCausesEndOfValue / lci:valueHasCauseOfEndOccurrence lci:classCausesEndOfValue / lci:valueHasCauseOfEndOccurrence 5.2.10.4 class_of_involvement_by_reference TBC * lci:classReferencesOccurrence / lci:classReferencedByOccurrence lci:classReferencesOccurrence / lci:classReferencedByOccurrence * lci:classReferencesValue / lci:valueReferencedByOccurrence lci:classReferencesValue / lci:valueReferencedByOccurrence * lci:valueReferencesOccurrence / lci:classReferencedByValue lci:valueReferencesOccurrence / lci:classReferencedByValue 5.2.10.5 class_of_participation N 5.2.10.6 class_of_recognition c1-c1 N 5.2.11 Relationships 5.2.11.1 other_relationship xx-xx N 5.2.11.2 relationship xx-xx N rdf:Property Abstract 5.2.12 Classes of relationship 5.2.12.1 class_of_assertion N 5.2.12.2 class_of_relationship lci:Mapping , TBC 5.2.12.3 class_of_relationship_with_related_end_1 N 5.2.12.4 class_of_relationship_with_related_end_2 N 5.2.13 Roles and domains 5.2.13.1 cardinality c2 N lci:domainMin , lci:domainMax , lci:rangeMin , lci:rangeMax OK similar functionality available in SHACL 5.2.13.2 class_of_relationship_with_signature N 5.2.13.3 participating_role_and_domain c2 N 5.2.13.4 role c2 N 5.2.13.5 role_and_domain c2 N 5.2.13.6 specialization_by_domain N 5.2.13.7 specialization_by_role N 5.2.14 Classes of class of relationship 5.2.14.1 class_of_class_of_relationship c2r lci:ClassOfMapping NO 5.2.14.2 class_of_class_of_relationship_with_signature N 5.2.14.3 class_of_scale c3r lci:ClassOfScale NO 5.2.15 Functions 5.2.15.1 class_of_functional_mapping N 5.2.15.2 class_of_isomorphic_functional_mapping lci:Isomorphism TBC 5.2.15.3 functional_mapping c1-c1 N ?? 5.2.16 Representations of things 5.2.16.1 definition c2-c1 TBC * lci:definitionBy * lci:definitionByInformationContent , * lci:definitionByInformationObject , * lci:definitionByLiteral, 5.2.16.2 description cx-c1 TBC * lci:descriptionBy , * lci:descriptionByInformationContent , * lci:descriptionByInformationObject 5.2.16.3 identification cx-c1 TBC * lci:identificationBy , * lci:identificationByInformationContent , * lci:identificationByInformationObject , * lci:identificationByLiteral 5.2.16.4 representation_of_thing cx-c1 TBC * lci:representationBy * lci:representationByInformationContent * lci:representationByInformationObject * lci:representationByLiteral 5.2.16.5 responsibility_for_representation c1-c1 N 5.2.16.6 usage_of_representation c1-c1 N 5.2.17 Classes of representation 5.2.17.1 class_of_definition lci:DefinitionSpace TBC 5.2.17.2 class_of_description lci:DescriptionSpace TBC 5.2.17.3 class_of_identification lci:IdentificationSpace TBC 5.2.17.4 class_of_information_representation c2 lci:InformationContent TBC 5.2.17.5 class_of_representation_of_thing lci:RepresentationSpace TBC 5.2.17.6 class_of_representation_translation lci:translationOf TBC 5.2.17.7 class_of_responsibility_for_representation N 5.2.17.8 class_of_usage_of_representation N 5.2.18 EXPRESS and UTC representations RDF literals of particular datatypes 5.2.18.1 EXPRESS_Boolean c2 c1 xsd:boolean 5.2.18.2 EXPRESS_binary c2 c1 xsd:hexBinary 5.2.18.3 EXPRESS_integer c2 c1 xsd:integer # to check if not xsd:long 5.2.18.4 EXPRESS_logical c2 c1 lci:logicalAsLiteral TBC 5.2.18.5 EXPRESS_real c2 c1 xsd:double 5.2.18.6 EXPRESS_string c2 c1 xsd:string OR lci:TextString, lci:textStringAsLiteral TBC 5.2.18.7 class_of_EXPRESS_information_representation c2 N 5.2.18.8 representation_of_Gregorian_date_and_UTC_time c2 c1 lci:iso8601IdentificationOfPointInTime OK 5.2.19 Classes of class of representation 5.2.19.1 class_of_class_of_definition c3r N 5.2.19.2 class_of_class_of_description c3r N 5.2.19.3 class_of_class_of_identification c3r N 5.2.19.4 class_of_class_of_information_representation c3 lci:ClassOfInformationContent TBC 5.2.19.5 class_of_class_of_representation c3r N 5.2.19.6 class_of_class_of_representation_translation N 5.2.19.7 class_of_class_of_responsibility_for_representation c3r lci:representationSpaceAssignedBy TBC 5.2.19.8 class_of_class_of_usage_of_representation c3r lci:representationSpaceUsedBy TBC 5.2.19.9 document_definition c3 lci:DocumentType 5.2.19.10 language c3 lci:Language TBC 5.2.19.11 representation_form c3 lci:RepresentationFormat TBC 5.2.20 Namespaces 5.2.20.1 class_of_left_namespace c3r N 5.2.20.2 class_of_namespace c3r N 5.2.20.3 class_of_right_namespace c3r N 5.2.20.4 left_namespace N 5.2.20.5 namespace N 5.2.20.6 right_namespace N 5.2.21 Connections 5.2.21.1 class_of_connection_of_individual No use lower level 5.2.21.5 connection_of_individual instead * lci:classConnectedToOccurrence No * lci:classConnectedToValue No * lci:valueConnectedToOccurrence No 5.2.21.2 class_of_direct_connection N 5.2.21.3 class_of_indirect_connection N 5.2.21.4 class_of_individual_used_in_connection N ?? 5.2.21.5 connection_of_individual c1-c1 lci:connectedTo OK a owl:SymmetricProperty 5.2.21.6 direct_connection c1-c1 lci:directlyConnectedTo OK 5.2.21.7 indirect_connection c1-c1 lci:indirectlyConnectedTo OK requires punning 5.2.21.8 individual_used_in_connection c1-c1 lci:individualUsedInConnection TBC not in ISO/TS 15926-12 5.2.22 Relative locations and sequences 5.2.22.1 class_of_containment_of_individual lci:containedBy / lci:contains TBC 5.2.22.2 class_of_relative_location TBC * lci:classLocatedRelativeToOccurrence * lci:valueLocatedRelativeToOccurrence * lci:classLocatedRelativeToValue 5.2.22.3 class_of_temporal_sequence TBC * lci:classAfterOccurrence / lci:classBeforeOccurrence * lci:classAfterValue / lci:valueBeforeOccurrence ERROR? * lci:valueAfterOccurrence / lci:classBeforeValue ERROR? 5.2.22.4 containment_of_individual c1-c1 lci:containedBy / lci:contains 5.2.22.5 relative_location c1-c1 lci:locatedRelativeTo TBC 5.2.22.6 temporal_sequence c1-c1 lci:before / lci:after OK 5.2.23 Lifecycle stages and approvals 5.2.23.1 approval cp-c1 N TBC requires punning, but how? 5.2.23.2 class_of_approval N 5.2.23.3 class_of_approval_by_status N 5.2.23.4 class_of_lifecycle_stage N lci:LifecycleStageClass OK different level 5.2.23.5 lifecycle_stage c1-c1 N lci:LifecycleStage OK requires punning 5.2.24 Possible and intended roles 5.2.24.1 class_of_intended_role_and_domain N 5.2.24.2 class_of_possible_role_and_domain N 5.2.24.3 intended_role_and_domain c1-c1 N 5.2.24.4 possible_role_and_domain c1-c1 N 5.2.25 Set operations 5.2.25.1 difference_of_set_of_class N 5.2.25.2 enumerated_set_of_class c3 N !!! 5.2.25.3 intersection_of_set_of_class N 5.2.25.4 union_of_set_of_class TBD 5.2.26 Properties 5.2.26.1 class_of_indirect_property N 5.2.26.2 comparison_of_property c2-c2 N 5.2.26.3 indirect_property c2-c1 N 5.2.26.4 multidimensional_property c2 5.2.26.5 property c2 N ?? 5.2.26.6 property_quantification N 5.2.27 Classes of property 5.2.27.1 boundary_of_property_space N 5.2.27.2 class_of_property c3 lci:ClassOfQuantity TBC 5.2.27.3 enumerated_property_set c3 N 5.2.27.4 lower_bound_of_property_range lci:quantityRangeHasLowerBound NO TBC 5.2.27.5 multidimensional_property_space c3 lci:CartesianProductOfQuantityKind TBC NO ?? 5.2.27.6 property_range c3 lci:PhysicalQuantityRange NO TBC 5.2.27.7 property_space c3 lci:PhysicalQuantitySpace 5.2.27.8 single_property_dimension c3 lci:PhysicalQuantityKind 5.2.27.9 upper_bound_of_property_range upper_bound_of_property_range NO TBC 5.2.28 Scale conversions 5.2.28.1 class_of_scale_conversion N 5.2.28.2 coordinate_system N 5.2.28.3 multidimensional_scale N 5.2.28.4 scale lci:Scale TBC 5.2.29 Shapes 5.2.29.1 class_of_dimension_for_shape c3r N 5.2.29.2 class_of_shape c3 N 5.2.29.3 class_of_shape_dimension c3 N 5.2.29.4 dimension_of_individual N 5.2.29.5 dimension_of_shape c3r N 5.2.29.6 individual_dimension c2 N 5.2.29.7 property_for_shape_dimension N 5.2.29.8 property_space_for_class_of_shape_dimension c3r N 5.2.29.9 shape c2 N ?? 5.2.29.10 shape_dimension c3 N 5.2.29.11 specialization_of_individual_dimension_from_property N Others defined in ISO/TS 15926-12 that are not part of ISO 15926-2\r#\rISO/TS 15926-12 SST-LCI Status Comment lci:powerClassOf - NO in principle OK, but not needed for SST-LCI lci:Non-actualIndividual y OK lci:Non-arrangedIndividual y OK lci:Non-wholeLifeIndividual y OK lci:PointOrPeriodInTime y OK not subtype of event * lci:PointInTime y OK not subtype of event * lci:PeriodInTime y OK lci:PointOrRegionInSpace y OK * lci:PointInSpace y OK * lci:RegionInSpace y OK lci:ClassOfClassOfInformationObject TBD lci:ClassOfComputerFile TBD lci:definitionBy lci:definitionByInformationContent lci:definitionByInformationObject lci:definitionByLiteral NO lci:descriptionOfExampleBy TBC lci:descriptionOfExampleByInformationContent TBC lci:descriptionOfExampleByInformationObject TBC lci:descriptionOfExampleByLiteral NO lci:noteBy * lci:noteByInformationContent * lci:noteByInformationObject * lci:noteByLiteral NO lci:ClassOfClassOfActivity NO lci:ClassOfClassOfPhysicalObject TBC lci:ClassOfPhysicalObject TBC lci:ClassOfPointInSpace lci:ClassOfPointInTime lci:ClassOfRegionInSpace lci:classBeginsOccurrence / lci:classHasBeginningOccurrence TBC lci:valueBeginsOccurrence / lci:classHasBeginningValue TBC lci:classHasCauseOccurrence / lci:classCausesOccurrence TBC lci:classHasCauseValue / lci:valueCausesOccurrence TBC lci:classEndsOccurrence / lci:classHasEndOccurrence TBC lci:valueEndsOccurrence / lci:classHasEndValue TBC lci:percent NO Others defined by SST that are not available in ISO 15926-2 or ISO/TS 15926-12\r#\rSST-LCI Status Comment lci:isDefinedBy / lci:isDefinitionFor OK lciSpaceTimeIndividual: OK lci:OtherIndividual OK any better name? lci:PointOrRegionInSpaceAndTime OK lci: lci:AnimateIndividual OK lci:DiscreteObject OK lci:ContinousObject OK lci:ChemicalElement OK lci:ChemicalSubstance OK lci:GasPhase ` OK lci:LiquidPhase ` OK lci:SolidPhase ` OK `lci:PlasmaPhase`` OK lci:AmorphousSolidPhase OK lci:CrystallineSolidPhase OK lci:ChemicalSubstance OK lci:ChemicalCompound OK lci:OrganicCompound OK lci:ChemicalMixture OK lci:HomogeneousChemicalMixture OK lci:HeterogeneousChemicalMixture OK lci:AstronomicObject OK lci: OK lci: OK lci: OK lci:ComputerFile lci:ComputerFileContent lci:ComputerFileFormat lci:ClassOfAbstractIndividual ?? ","externalUrl":null,"permalink":"/sst_ontologies/lci_15926_mapping/","section":"SST Ontologies","summary":"","title":"ISO 155926 mapping","type":"sst_ontologies"},{"content":"SST and EDM is a joint software development project of DCT Co. Ltd. in China and the Semantic STEP Technology GmbH in Germany that is a subsidiary of LKSoft.\n德中（天津）技术发展股份有限公司\nDCT Co.,Ltd.\nPlaza C, No.11 HuaKeYiLu, HaiTai, XiQing District\nTianjin, 300392, P.R.China\nTel.: 022-83726907 Fax:022-83726903\nSemantic STEP Technology GmbH\nSteinweg 1\n36093 Künzell, Germany\nCourt of registration: Fulda, HRB 7994\nUSt-IdNr / VAT-ID: DE342668514\nResponsible for the contents of this web site is Lothar Klein, general manager of Semantic STEP Technology GmbH.\nDisclaimer:\nIn spite of careful checking we do not accept liability for the content on the linked websites. Only the owners of these websites are responsible for the content.\nTrademarks: Products mentioned in this website are for identification purposes only and may be trademarks or registered trademarks of their respective companies.\n\u0026hellip; ","externalUrl":null,"permalink":"/footer/legal/","section":"Footers","summary":"","title":"Legal","type":"footer"},{"content":"TBD\nSST-LCI \u0026mdash; the Life-Cycle Integration ontology of SST \u0026mdash; is derived from ISO 15926 \u0026ldquo;Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities\u0026rdquo;; in particular ISO 15926-2:2003 for the \u0026ldquo;Data model\u0026rdquo; and ISO/TC 15926-12:2018 on \u0026ldquo;Life-cycle integration ontology represented in Web Ontology Language (OWL)\u0026quot;.\nSST-LCI uses the same 4D approach to describe all the things around us. SST-LCI differs significantly from the ISO 15926 data model is several respects with the consequence that only some 50% of the ISO 15926 definitions are used in exactly the same way in SST-LCI. The main differences are:\n","externalUrl":null,"permalink":"/sst_ontologies/lci/","section":"SST Ontologies","summary":"","title":"Life-Cycle Integration","type":"sst_ontologies"},{"content":"\rNews\r#\r2026-04-27: DCT Co. Ltd., China, and SST GmbH, Germany, release together SST-Core v1.0.0 and make it available under a dual licensing model, consisting of commercial licenses and the POLYFORM Noncommercial 1.0.0 license. The sources are available on https://github.com/semanticstep/sst-core .\nSST stands for Semantic STEP Technology. SST-Core is a toolkit for the development of applications with a focus on industrial product data as created and managed by CAD, CAM, PDM, PLM, LSA, ERP, Process- and Manufacturing-Planning systems.\nSST-Core has a novel architecture that allows the use of Semantic Web standards RDF/S, OWL, Turtle, TriG in a performance optimized way that is suitable for cloud computing and able to drive e.g. web applications. SST Repositories allow distributed storage and replication of data on the Internet with full revision control. With integrated GIT functionality it is always possible to analyze the history of each Dataset to answer the question of who, when, what, why of each change.\nSST-Core provides higher level ontologies for industrial product data that integrate modelling concepts from other international standards together in a unified single level data model; thus bridging between major incompatibilities between these standards, including:\nLife-cycle Integration (LCI) as defined in the ISO 15926 series for process plants including oil and gas production facilities STEP, the STandard for the Exchange of Product model data, ISO 10303 series; IEC Common Data Dictionary (CDD), including IEC 61360-4 for electric/electronic components ISO/IEC 81346 Standard Series on Reference Designation System (RDS) ASD S3000L on Logistic Support Analysis (LSA) ISO/IEC 80000 on Quantities and Units DCT Co. Ltd., and SST GmbH are working together to release the end-user web application SST-EDM which stands for \u0026ldquo;Engineering Data Management\u0026rdquo; later in 2026. SST-EDM runs on top of SST-Core and will step by step implement many of the capabilities listed here.\nHistory\r#\rThe development of a Semantic STEP Technology started back in early 2021 after several major decisions where taken by Lothar Klein on how to create a complete new framework for all kinds of CAx related applications hosted on the web. These decisions are based on his almost 40 years of software development experiences on CAD, CAM and PDM/PLM systems and the experiences with the development of data exchange and integration standards, primarily on EDIF and STEP within ISO TC184/SC4. The main decissions where:\nGO as the main server side programming language. Previous systems Lothar implemented uses Java (JSDAI and IDA-STEP), C/C++ (CircuitCAM), Pascal (ColorCAM) RDF/S as the basis to store all application data and higher level ontologies, and Turtle to visualize this data. Unlike other formats such as STEP Express and p21 format, relational databases, linked data databases, XML, Json and others misses the capabilities that are provided by using the full power of RDF/S. For performance reasons to use NamedGraph (that can contain many triples) as the main objects for persistent data storage in a database - and to separate this from querying needs for which a separate database with derived data that is optimized for any kind of index needed. This is the opposite approach to RDF and Linked Data storage solutions that uses SPARQL as the main access mechanism. Triplex structure in memory that enable to traverse graphs of RDF triples in any direction at high speed: from subject to predicate and object from object nodes to predicate and subject from predicate to subject and object To use OWL as logical basis for data modelling; but not to rely on general purpose reasoning/inferencing with Open World assumption. Instead require for each node (IRI and blank ones) to explicitly state of which type it is to allow validation based on the Closed World assumption Use of OWL 2 that introduces owl:imports by which it can be explicitly stated which NamedGraph belong to a Dataset that defines this Closed World for validation GIT like revision control capabilities on the basis of NamedGraphs with full commit, branch, diff and merge capabilities. \u0026ldquo;early binding support\u0026rdquo; to make key classes and properties directly accessible as GO objects; simplifying the development of e.g. converters significantly. In Mai 2023 a first stable pre-release of basic SST-Core functionality was release to an industrial customer who uses it in a productive web application. Since then the programming interface has been significantly optimized and missing capabilities where added.\nImplementation Status\r#\rWith this SST-Core v1.0.0 release the following components of SST-Core are considered to be stable and ready for productive use:\nmain library functionality in package git.semanticstep.net/x/sst/sst SST Repository, local and remote SST Ontology Compiler and the generated early binding support SST CLI - Command Line Interface The following components are currently in draft state:\nhigher level SST Ontologies such as lci, sso, rep STEP import and export in p21 and XML format Diff and merge functionality ","externalUrl":null,"permalink":"/news/","section":"News","summary":"","title":"News","type":"news"},{"content":"ProductFamily TBD\nProduct Family of MIL-STD-38999 connectors in EDM ","externalUrl":null,"permalink":"/edm/configuration/","section":"SST-EDM Overwiew","summary":"","title":"Product Families \u0026 Configuration","type":"edm"},{"content":"\rSST Core is not a general purpose RDF toolkit\r#\rSST Core is highly optimised in various ways for speed and efficiency. To achieve this goal certain restrictions are introduced, with the result that SST Core is not a general purpose RDF toolkit. In practise this means, every RDF file generated with SST-Core is valid according to the W3C standards, but not every RDF file can be imported into SST Core.\nIn detail the RDF restrictions are:\nevery Datasets is identified by an URI (URN or URL) without any fragment every NamedGraph is identified by an URI (URN or URL) without any fragment even the default graph of a Dataset is a NamedGraph in SST, and this default NamedGraph has the same URI as the Dataset (for which it is the default one) IBNodes are owned and located in exactly one NamedGraph with the same base URI plus a fragment; only the owning NamedGraph can contain triples with the owned IBNodes as subject in addition to the above each NamedGraph has an implicitly IBNode that has the same URI as the NamedGraph with no fragment; this is used to make statements about the NamedGraph blank node can be referenced as object only within the same NamedGraph where they are defined ","externalUrl":null,"permalink":"/overview/limitations/","section":"SST Overview","summary":"","title":"RDF Constraints","type":"overview"},{"content":"SST data is RDF data and thus follows the definitions as provided in the W3C Recommendation RDF 1.1 Concepts and Abstract Syntax:\nThe Resource Description Framework (RDF) is a framework for representing information in the Web. This document defines an abstract syntax (a data model) which serves to link all RDF-based languages and specifications. The abstract syntax has two key data structures:\nRDF graphs are sets of subject-predicate-object triples, where the elements may be IRIs, blank nodes, or datatyped literals. They are used to express descriptions of resources.\nRDF datasets are used to organize collections of RDF graphs, and comprise a default graph and zero or more named graphs. RDF 1.1 Concepts and Abstract Syntax also introduces key concepts and terminology, and discusses datatyping and the handling of fragment identifiers in IRIs within RDF graphs.\nBased on the RDF definitions the following keywords are used throughout SST:\nDataset: consisting of the default NamedGraph and other directly or indirectly imported NamedGraph and to some degree other referenced only NamedGraphs\nNamedGraph: consisting of Triples that are interlinked by sharing the same nodes\nTriple: consisting of 3 Resources in the role Subject, Predicate and Object. Depending on how a particular node is used in a triple we identify the triple as Subject Triple, Predicate Triple or Object Triple.\nIBNode: either an IRI Node or a BlankNode. A BlankNode might be a Collection (see Turtle)\nLiteral: a data value that is not a node, but that has a Datatype\nResource: either an IBNode or a Literal\nFragment: identifier that provides a secondary resource of an IRI-Node\nBeyond of what is defined in RDF, SST adds further restrictions:\nFor the purpose of SST the RDF concepts of a NamedGraph and Namespace are unified in the way that each NamedGraph has it\u0026rsquo;s own base URI without a fragment that is also establishing a Namespace with an associated prefix, either a default one or a dynamically assigned one. The consequences are:\nEvery NamedGraph is identified by its namespace URI (Uniform Resource Identifier) that is either a URN (Uniform Resource Name) or a URL (Uniform Resource Locator). The namespace URI of a NamedGraph must not have a Fragment each NamedGraph can be represented in a single Turtle file (or any other RDF format) a collection of NamedGraph \u0026mdash; e.g. the ones that make up a Dataset \u0026mdash; can be represented as a single TriG file the base IRI of all IRI nodes in a NamedGraph that are used as subject, must be the same as the IRI of the NamedGraph with an additional fragment. As a consequence every IRI node is owned by exactly one NamedGraph. in addition every NamedGraph contains one implicit IRI node that has no fragment and that represents the whole NamedGraph as an owl:Ontology. similar blank nodes defined in a NamedGraph can only be referenced from within this NamedGraph. The default graph of a Dataset is also treated as a NamedGraph and so the Dataset is identified by the same URI as it\u0026rsquo;s default NamedGraph\nfor every IBNode at least one subject triple with the predicate rdf:type must be defined from which the base nature of this IBNode can easily be deduced, so on whether it is a class, an individual or a property (see further details under xxx-TBD)\nThere are two ways on how NamedGraphs other than the default NamedGraph are used in a Dataset; either by explicitly importing these NamedGraph using owl:imports or by just referencing the whole NamedGraph or single IRI-nodes in it. On whether another NamedGraph is imported or only referenced has the following consequences:\nSST operates on a closed world assumption for a Dataset. The closed world is primarily defined by the default NamedGraph together with all directly or indirectly imported NamedGraph. A \u0026ldquo;window\u0026rdquo; from the closed world to the open world is provided by other NamedGraph that are only referenced. Validating a Dataset is by default only done for the default NamedGraph together with all directly and indirectly imported NamedGraph. NamedGraph that are only referenced (other than the default SST ontologies) are not validated. The SST Core provides Revision Control of a Dataset only for the default NamedGraph together will all directly and indirectly imported NamedGraphs. NamedGraphs that are only referenced are not under Revision Control These restrictions are widely used outside of SST anyway; but for performance and validation reasons SST insists that these restrictions are not violated.\nSST is widely using random Version 4 UUIDs (Universally unique identifier) for application data; as both UUID-URNs and as Fragment. So a typical NamedGraph may be identified as\nurn:uuid:fa446d9a-429e-4c73-a860-d87ff7ac7d79\nand an IRI node of this NamedGraph as\nurn:uuid:fa446d9a-429e-4c73-a860-d87ff7ac7d79#8287edba-f6c1-407e-bc93-e16efa016129.\nMain reason for this is that application data can freely be used between different organisations without enforcing any ownership in the data itself. In addition the random nature ensures that not by chance the same IRI is used twice for different purpose.\n","externalUrl":null,"permalink":"/overview/rdf/","section":"SST Overview","summary":"","title":"RDF Specifics","type":"overview"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"\rSST Core is not a general purpose RDF toolkit\r#\rSST Core is highly optimised in various ways for speed and efficiency. To achieve this goal certain restrictions are introduced, with the result that SST Core is not a general purpose RDF toolkit. In practise this means, every RDF file generated with SST-Core is valid according to the W3C standards, but not every RDF file can be imported into SST Core.\nIn detail the limitations are:\nevery NamedGraph is identified by an URI (URN or URL) without any fragment IBNodes are located in exactly one NamedGraph with the same base URI plus a fragment NamedGraph IBNode has the same URI as the NamedGraph every Datasets is identified by an URI (URN or URL); the default graph of a Dataset is also a NamedGraph with the same URI as the Dataset blank node can be referenced as object only within the same NamedGraph where they are defined ","externalUrl":null,"permalink":"/sst_core/","section":"SST Core","summary":"","title":"SST Core","type":"sst_core"},{"content":"meta TBD\n","externalUrl":null,"permalink":"/sst_ontologies/meta/","section":"SST Ontologies","summary":"","title":"SST Meta Directives","type":"sst_ontologies"},{"content":"SST comes with a set of pre-defined higher level ontologies. These are in hierarchical order (together with the standard used prefix):\nthe basic Ontologies as defined by the W3C Semantic Web are: RDF(rdf) and RDFS(rdfs) for the basic concepts such as Triple, NamedGraphs, Datasets and more OWL 2(owl) for the logical layer common datatypes defined in XML-Schema(xsd) SKOS(skos), the Simple Knowledge Organization System Reference SHACL(sh), the Shapes Constraint Language to define data model constraints; no yet implemented the fundamental ontologies that are application independent are on top of the basic ontologies: SSMETA(ssmeta) to direct the SST-Core on how to operate LCI(lci) \u0026ldquo;Live Cycle Integration\u0026rdquo; that is derived from the ontology defined in ISO/TS 15926-12 to support the concepts defined in the data model of ISO 10303-2 Quantities \u0026amp; Units(qau) as defined in ISO 80000 the STEP related ontologies and other application oriented ontologies are on top of the fundamental ontologies: all STEP definitions on Representation(rep), based on ISO 10303-43 and many other parts out of the ISO 10303 series of standards. This includes geometry, topology, presentation \u0026amp; styling, kinematics and others STEP PDM(sso) \u0026ndash; Product Data Management \u0026ndash; concepts that are primarily extracted from the Domain Model of STEP AP242 as defined in ISO/TS 10303-4442 \u0026ldquo;Managed model-based 3D engineering domain\u0026rdquo; Schematic Diagrams(eed) Reference data ontologies IEC Common Data Dictionary as defined in IEC 61360 (draft) \u0026hellip; more reference data sources to be added over time The SST ontologies form a single level data mdel.\nNot for any particular business case\r#\rTypically data-models are created to support a well specified business case - or a few related ones. This is not been the case for the SST-Ontologies. The focus is here to describe the nature of things around us; those we can touch and also those we can imagine, covering the past, presence and future.\nProperties as first class citizens\r#\rTypically it is said that RDF triples are used to represent a graph with the subjects and object as the graph nodes and the predicates as the graph edges. In this model the RDF properties that are used for the predicates are defined in special higher level ontologies and there is a limit number of them. Application data are not defining any new RDF properties but only using the ones in the upper level ontologies as predicates in triples. This concept is similar to traditional modelling concepts such as Express (ISO 10303-11) and UML/SysML where application data can defines instances of the defined entities/classes, but are not allowed to define \u0026ldquo;instances\u0026rdquo; of properties.\n","externalUrl":null,"permalink":"/sst_ontologies/","section":"SST Ontologies","summary":"","title":"SST Ontologies","type":"sst_ontologies"},{"content":"Q\u0026amp;U TBD\n","externalUrl":null,"permalink":"/sst_ontologies/qau/","section":"SST Ontologies","summary":"","title":"SST Ontologies","type":"sst_ontologies"},{"content":"Semantic STEP Technology (SST) is a novel way to represent, integrate and manage industrial product data as it is used in CAD, CAM, PDM, PLM, ERP and other CAx system. SST is optimised to work on the Internet using cloud computers. To achieve highest performance, SST is implemented in Golang and is using the underlying Semantic Web standards in a specific way with several restrictions.\nMajor components of the SST Core are:\r#\rSST Ontologies: A set of higher level ontologies on top of OWL 2, defining the underlying data model of SST. Basis is a Life-cycle Integration (LCI) ontology that is derived from ISO 15926 that allows a consistent representation of individuals with all their changes throughout space \u0026amp; time. On top of LCI other ontologies are provided for STEP (ISO 10303), Quantities and Units (ISO/IEC 80000), Reference Designation Systems (ISO/IEC 81346), Part Dictionaries \u0026amp; Libraries (ISO 13584 \u0026amp; IEC 61360) and more. Together the SST Ontologies provide an integrated single level data model that overcomes many limitation and artificial complexity of the underlying standards.\nSST Data: All SST application data as well as the SST Ontologies is directly accessible as standard RDF exchange files (primarily in Turtle and Json-LD format) and is so available for other tools. However not every RDF file can directly be imported into SST as the data must be structured in a specific way to enable the overall performance and flexibility of SST. Part of this is that SST is not relying on any exhaustive reasoning/inferencing but instead requires a specific data organisation.\nSST API : Application programming interface with the combination of the following unique features:\ncompletely written in GO programming language; the most efficient way for web applications late and early binding support. With early binding for each ontology concept a direct GO constructs are available; generated by the SST Compiler. This makes application programming straight forward triplex structure for being able to traverse an RDF graph that consists of triples in any direction SST Core API/Library: A Semantic Web engine to support OWL 2 (and thus RDF, RDFS). Note that the SST Core is not a general purpose RDF toolkit as it is highly specialised for performance and the specific way how SST deals with application data. The build in triplex structure allows for fast traversing an RDF graph in any direction (starting from either subject, predicate or object). Implemented in Golang ensures fastest possible performance on cloud computers.\nGIT like revision control capabilities to enable collaborative work on RDF data. GIT is very widely used system for software development, that provides a database for source code with strict revision control capabilities for each piece of source code. This includes commits, splitting the sources into branches and independent development, but being able to merge them afterwards. SST is providing the same kind of capabilities for NamedGraphs that define a set of triples (typically contained in an RDF file)\nSST Repository: An integrated part of of the SST Core to make SST Data accessible on the Internet, together with built in revision control that follows principles of the GIT revision control system.\nSST Repository ; either remote or local for the persistent storage of RDF data grouped into NamedGraphs and Datasets. A remote SST Repository is the default way for SST to publish data on the web\nSST Converter:\nSST Ontologies and SST Data organisation are publicly documented. SST Core, SST Repository and SST EDM are available on a commercial basis.\n","externalUrl":null,"permalink":"/overview/","section":"SST Overview","summary":"","title":"SST Overview","type":"overview"},{"content":"Together with the ontologies defined in RDF and RDF-S, SST is using the OWL 2 Web Ontology Language / Document Overview as it\u0026rsquo;s basic foundation. All logical statements from OWL 2 might be used in SST. However there are differences on the impact of these statements that are explained here.\nFor SST an Ontology corresponds to Dataset in RDF; so every Dataset is an Ontology that can import other ontologies.\nOWL 2 is defined for the open-world assumption, meaning there might be facts defined outside of the current Dataset that might heavily impact the semantics of the data defined in this dataset. On the other hand typical database applications are using the so called closed-world assumption; that is, facts that are not defined in the database are not there. SST is based on this closed-world assumption for each dataset. A direct consequence of the closed-world assumption is that any two IBNodes used within the same Dataset in any triple as either subject, predicate or object define two different objects unless it is explicitly stated within the Dataset that they are the same object using owl:sameAs.\nSST requires the capabilities of OWL 2 Full, the OWL 2 RDF-Based Semantics. The subset OWL 2 DL, the OWL 2 Direct Semantics that is using a functional-style syntax is not suitable for SST because of the extensive use of Punning; see below. Also the OWL 2 profiles EL, RL and QL are not suitable for SST for the same reasons.\nNote that several related standards are based on OWL 2 DL and therefore can\u0026rsquo;t take advantage of OWL 2 Full including of Punning Individuals with Classes and Properties. These are e.g.:\nISO/AWI 23726-100 Automation systems and integration — Ontology based interoperability — Part 100: Schedule data ontology\nISO/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)\nFigure 1: Parts Hierarchy of the OWL 2 RDF-Based Semantics (from OWL 2 RDF-Based Semantics)\nIn general, using OWL Full might result in extreme long computation time for reasoning (also called inferencing) on the provided data. This is not the case in SST because of the closed-world assumption (see above) and the requirement to specify for each node basic rdf:type information. With a suitable toolkit such as the SST Core it is possible to process RDF in very high speed.\nWith the constraints stated here OWL facts can directly be used to validate SST data:\nSST adopts the \u0026ldquo;unique names assumption\u0026rdquo;; this is not the case for OWL\nfor every IBNode a subject-triple with predicate rdf:type and an object of type owl:Class for application data or rdfs:Class for SST ontologies must exist\nthe predicates of all triples must be of rdf:type rdf:Property or one of it\u0026rsquo;s sub-properties owl:ObjectProperty, owl:DatatypeProperty, owl:OntologyProperty or owl:AnnotationProperty. If the predicate is defined within the Dataset to be validated, then it must in addition be defined to be a rdfs:subPropertyOf one of the properties defined in one of the SST ontologies\nan owl:FunctionalProperty can be used only once for the subject of a triple; otherwise it is an error\nan owl:InverseFunctionalProperty can be used only once for the object of a triple; otherwise it is an error\nthe subject of every triple must be explicitly defined to be of the type as defined for the rdfs:domain of the predicate, or an rdfs:subClassOf that type\nthe object of every triples must be of the type as defined for the type as defined for the rdfs:range of the predicate, or an rdfs:subClassOf that type\nan owl:TransitiveProperty must no be used cyclically\n\u0026hellip; to be extended\n","externalUrl":null,"permalink":"/overview/owl/","section":"SST Overview","summary":"","title":"SST OWL Specifics","type":"overview"},{"content":"\rSST — Command-line reference\r#\rNAME\r#\rsst — Semantic STEP Technology core command-line interface for repositories, datasets, and RDF stages\nSYNOPSIS\r#\rsst [-h | \u0026ndash;help]\nsst interactive\nsst version\nInside interactive mode (after the sst \u0026gt; prompt), commands are free-form lines; see INTERACTIVE SYNTAX below.\nDESCRIPTION\r#\rsst is a low-level CLI used to debug and exercise the SST Core API against local or remote SST repositories, SuperRepositories, datasets, mutable stages, named graphs, and IBNodes. Most work happens in interactive mode: a terminal session that prints a sst \u0026gt; prompt, reads one line of input, runs that command, prints any output, and repeats (using the readline library when available for editing, history, and Tab completion). Resources get short aliases (r1, d1, …) and operations often use the alias.command pattern.\nThe default invocation (sst with no subcommand) starts interactive mode, equivalent to sst interactive.\nFor a narrative guide, examples, and background, see CLI_INTRODUCTION.md.\nOPTIONS\r#\rThe top-level sst command is implemented with Cobra. Only the following generic options apply at the root; subcommands do not currently add their own flags beyond Cobra’s defaults.\n-h, \u0026ndash;help\nPrint help for sst (and, when shown for the root command, a short footer pointing to interactive mode).\nCobra may also accept \u0026ndash;help on subcommands (e.g. sst interactive --help).\nThere is no top-level -v / \u0026ndash;version flag; use sst version instead.\nCOMMANDS\r#\rinteractive\nStart interactive mode: print the same startup line as a bare sst run(read lines after sst \u0026gt;, dispatch commands, until q). Behavior matches sst with no subcommand; sst interactive is only an explicit way to enter that mode from the shell. No arguments.\nversion\nPrint one line of version information and exit. Implementation: cli/cmd/version.go. No arguments.\nINTERACTIVE SYNTAX\r#\rPrompt\nThe prompt is sst \u0026gt; .\nQuitting\nLine q exits interactive mode and ends the process (after closing the readline session).\nTokens\nInput is split on whitespace for standalone commands. For alias.command lines, the first . separates the alias from the rest; the rest is then split with strings.Fields for the subcommand and its arguments.\nCase\nStandalone keywords such as help may be matched case-insensitively where implemented. The subcommand name after the dot is normalized with strings.ToLower (so r1.commitInfo and r1.commitinfo both resolve to the same handler).\nOptional resource alias\nMany opening and checkout commands accept -a alias to choose the alias for a new repository, stage, etc. If -a is omitted, the CLI picks the next free default (r1, r2, … / s1, …).\nGrammar (summary)\nForm Meaning word args… Standalone command (e.g. help, status, openlocalrepository). alias.subcommand args… Operation on an opened resource (e.g. r1.info, d1.history). Readline\nWhen the readline library initializes successfully: Tab completion for top-level commands, aliases, and alias. subcommands; history file (see FILES). Ctrl+D sends EOF and exits. Ctrl+C aborts the current line and reminds you to use q to quit. If readline fails to start, the CLI falls back to a simple reader (no history/completion).\nINTERACTIVE COMMANDS\r#\rThe following tables mirror the built-in help output and the dispatch logic in cli/cmd/interactive. Arguments in angle brackets are required unless noted.\nSession\r#\rCommand Description q Exit interactive mode. help Print the full command list (same categories as below). status List opened repositories, datasets, stages, named graphs, IBNodes and aliases. Opening and imports (no leading alias)\r#\rCommand Description openlocalrepository path [-a alias] Open a local SST repository. openlocalflatrepository path [-a alias] Open a local “flat” repository (directory of .sst files). openremoterepository URL [-a alias] Open a remote repository (TLS; auth via provider / credentials; see ENVIRONMENT). openlocalsuperrepository path [-a alias] Open a local SuperRepository. openremotesuperrepository URL [-a alias] Open a remote SuperRepository. rdfread file Load Turtle or TriG into a new stage (new alias). importap242xml file Import AP242 XML into a new stage. importp21 file Import STEP P21 into a new stage. repo — repository alias\r#\rCommand Description info Repository metadata (sizes, counts, remote flags, index, …). close Close this repository in the session. superrepository If this repo belongs to a SuperRepository, show that linkage/info. datasets List datasets. dataset iri Open dataset by IRI (new dataset alias). query bleve-query [\u0026ndash;limit n] Bleve full-text query over the repository index. queryuuid uuid Query index document by UUID. listfield List indexed Bleve field names. log [-v | \u0026ndash;verbose] Repository commit log; verbose for details. commitInfo commit-hash Details for one commit (camel or lower case accepted). commitdiff commit-hash NamedGraph-level diff vs parent(s): added / modified (triple diff) / deleted graphs. extractsstfile hash Extract raw SST bytes for a NamedGraphRevision hash. dump bucket-key[**/**sub-key] Dump internal Bolt buckets (ngr, dsr, c, ds, dl); dangerous on production data. openstage Create an empty stage on this repo. syncfrom source-repo-alias [branch] [dataset …] Copy/sync from another open repository (see in-app usage text for branch and dataset selection). clone target-directory Clone repository to a local directory. documentinfo hash Document metadata. documents List documents. documentdelete hash Delete document by hash. documentset file Upload a document file. documentget hash output-path Download document by hash. dump bucket keys: ngr (NamedGraphRevisions), dsr (DatasetRevisions), c (Commits), ds (Datasets), dl (DatasetLog).\nsuperrepo — SuperRepository alias\r#\rCommand Description info SuperRepository info. close Close SuperRepository session. list List contained repositories. get repo-name Open a member repository (gets a normal r* alias). create repo-name Create member repository. delete repo-name Delete member repository. dataset — dataset alias\r#\rCommand Description listcommits [\u0026ndash;details] Walk history from leaf commits; optional detailed rows. commitsbyhash hash Show commit by hash. commitsbybranch branch Show commit at branch tip. branches List branches and commit hashes. leafcommits List leaf commit hashes only. checkoutcommit hash [-a stage-alias] Materialize a stage at a commit. checkoutbranch branch [-a stage-alias] Materialize a stage at a branch tip. diff NGR-hash1 NGR-hash2 Triple-level diff between two NamedGraphRevision hashes. history Print/visualize dataset commit history graph. stage — stage alias\r#\rCommand Description info Stage statistics (graphs, triples, …). namedgraphs List named graphs in the stage. referencednamedgraphs List referenced named graphs. namedgraph iri Resolve graph by IRI (new graph alias). moveandmerge source-stage-alias Merge graphs from another open stage into this stage. commit message [branch] Commit staged changes. validate RDF / domain-range validation. rdfwrite file Write stage as TriG. trig Print stage TriG to stdout. namedgraph — named graph alias\r#\rCommand Description info Graph metadata and revision pointers. foririnodes List IRI nodes. forallibnodes List IRI and blank nodes. forblanknodes List blank nodes only. getirinodebyfragment id Resolve IRI node by fragment id. getblanknodebyfragment id Resolve blank node by fragment id. rdfwrite file Write Turtle for this graph. exportap242xml file.xml Export AP242 XML. ttl Print Turtle to stdout. ibnode — IBNode alias\r#\rCommand Description forall List triples in which this IBNode appears. info on multiple kinds\r#\rThe info subcommand is dispatched by alias type: SuperRepository, repository, stage, or named graph (not dataset in the current code path).\nENVIRONMENT\r#\rSST_USERNAME, SST_PASSWORD\nIf both are set, non-interactive username/password may be supplied for token acquisition paths used when opening remote resources (see cli/cmd/utils/gettoken.go). Storing passwords in the environment is a security risk on shared machines; prefer interactive entry when possible.\nOther variables depend on the host OS and gRPC / TLS stack; there are no additional SST-specific variables required for local-only use.\nFILES\r#\r$HOME/.sst_cli_history (or the user profile home directory on Windows)\nStores up to the last 1000 interactive input lines when readline is active.\nDIAGNOSTICS\r#\rExit status is 0 on normal completion of the sst process. Non-zero exit codes are propagated from Go’s os.Exit paths only where explicitly set; many interactive errors print a message and return to the prompt without exiting the program.\nBUGS\r#\rInteractive mode is intended for development and operations support, not as a stable scripting API: command spelling and available subcommands evolve with the Core API.\nSEE ALSO\r#\rCLI_INTRODUCTION.md — tutorial-style guide, workflows, and merged design notes from the legacy index.\nProject layout: build the binary with\ngo build -o cli/sst ./cli/main.go\nfrom the repository root unless your packaging uses another output path.\n","externalUrl":null,"permalink":"/sst_core/cli_ref/","section":"SST Core","summary":"","title":"SST-CLI: Command Line Interface Reference","type":"sst_core"},{"content":"The SST Core \u0026ldquo;Command Line Interface\u0026rdquo; tool CLI is a low level tool for debugging and testing the SST Core and Repositories.\nCLI is working within a terminal window (e.g. a bash terminal). If the tool is not yet build you can do so by invoking the following command that is creating the sst executable.\n$ go build -o cli/sst ./cli/main.go\rThe CLI tool is started by invoking the sst executable.\n$ ./sst Entering SST CLI tool in interactive mode. Type \u0026#39;q\u0026#39; to quit, \u0026#39;help\u0026#39; to see available commands. sst \u0026gt; q Exiting SST CLI tool\rCLI\r#\rCommand line Interface (CLI) to SST\nThe (planned) command line application sst - we name it SST-CLI - is similar to the \u0026ldquo;git\u0026rdquo; command line application as defined in https://git-scm.com/docs. This means that SST functionality, that is equivalent to GIT functionality will has the same or at lease similar commands, options and interface.SST-CLI is implemented directly on top of the SST-Core API.\nMain use cases for SST-CLI is to:\nto play with and test out SST functionality being able to easily provide SST test cases without developing software being able to identify and report issues that might be in the core SST API, but without the need of programming being able to execute specific functionality that an SST application might not (yet) support But unlike the GIT-CLI, the SST-LCI is not intended to be used on a daily basis to work with SST data. All checked out SST data will be presented to and accepted from the user in the form of readable Turtle (.ttl) files. These Turtle (.ttl) files will be named by their corresponding NamedGraph UUID. Question is on how to show the user also the corresponding URL if provided? The Turtle files will be stored in a flat working directory (instead of the working tree in GIT). Note that SST stores internally all data in the form of SST binary files that a user can not easily inspect.\nLike GIT, the SST-CLI is supporting a local SST repository (storage type with history information); but his should be optional. Users should also be able to directly work to/from a remote SST repository without a local one. Configuration data and the optionally local SST Repository will be be stored in a (hidden) sub-directory .sst, similar to the .git directory for GIT.\nCheckout of SST data is done on Datasets, and so consequently the resulting working directories will be identified by the UUID of the datasets followed by \u0026ldquo;_\u0026rdquo; and the branch name. By default the working directories are stored in parallel to the .sst directory.\nSST commands\r#\rBig question: In git, the current path defines the \u0026ldquo;git repository\u0026rdquo; to use. Do we want to have something similar for SST CLI?\nsst-version\r#\r$ sst --version\rsst-statistics\r#\r$ sst --statistics\r\u0026hellip; many more commands to follow\r#\r[[CLI comparison]] with GIT-CLI\nNaming of parameters:\nr1, r2, r3 \u0026hellip; Repositories d1, d2, d3 \u0026hellip; Datasets s1, s2, s3 \u0026hellip; Stages g1, g2, g3 \u0026hellip; NamedGraphs n1, n2, n3 \u0026hellip; IBNodes c1, c2, c3 \u0026hellip; collections the numer 1, 2, 3 will automatically be assigned by sst-cli, next free one Example: sst\u0026gt; OpenRemoteRepository \u0026hellip; # any command repository opened # tell the user about the result sst\u0026gt; r1.Close repository is closed sst\u0026gt; Statistics error: not opened Basic Usage\r#\rGetting Help\r#\rAt any time, type help to see all available commands:\nsst \u0026gt; help\rThis displays a comprehensive list of interactive commands organized by category.\nStatus and Information\r#\rCheck the current state of opened resources:\nsst \u0026gt; status\rThis shows all currently opened repositories, datasets, stages, named graphs, and IBNodes with their aliases.\nCommand Syntax\r#\rCommands in the CLI follow a pattern of \u0026lt;alias\u0026gt;.\u0026lt;command\u0026gt; for operations on specific resources. Resources are automatically assigned aliases when opened (e.g., r1, r2 for repositories; d1, d2 for datasets; s1, s2 for stages).\nRepository commands: \u0026lt;repo-alias\u0026gt;.\u0026lt;command\u0026gt; Example: r1.info, r1.datasets, r1.close Dataset commands: \u0026lt;dataset-alias\u0026gt;.\u0026lt;command\u0026gt; Example: d1.commitsbyhash \u0026lt;hash\u0026gt;, d1.history, d1.checkoutbranch \u0026lt;branch\u0026gt; Stage commands: \u0026lt;stage-alias\u0026gt;.\u0026lt;command\u0026gt; Example: s1.validate, s1.commit \u0026quot;message\u0026quot;, s1.namedgraphs NamedGraph commands: \u0026lt;namedgraph-alias\u0026gt;.\u0026lt;command\u0026gt; Example: g1.info, g1.foririnodes, g1.ttl IBNode commands: \u0026lt;ibnode-alias\u0026gt;.\u0026lt;command\u0026gt; Example: n1.forall SuperRepository commands: \u0026lt;superrepo-alias\u0026gt;.\u0026lt;command\u0026gt; (aliases are often sr1, sr2, …) Example: sr1.list, sr1.get my-repo Standalone commands: Direct commands without alias Example: help, q, status, rdfread Repository Commands\r#\rOpening Repositories\r#\rOpen a local repository:\nsst \u0026gt; openlocalrepository /path/to/repository\rThis opens a local SST repository and assigns it an alias (e.g., r1).\nOpen a flat local repository (a directory of .sst files):\nsst \u0026gt; openlocalflatrepository /path/to/flat-repo\rOpen a remote repository:\nsst \u0026gt; openremoterepository https://example.com/repo\rThis opens a remote SST repository via URL and assigns it an alias.\nOpen a SuperRepository (local path or remote URL); see SuperRepository Commands:\nsst \u0026gt; openlocalsuperrepository /path/to/superrepo sst \u0026gt; openremotesuperrepository https://example.com/superrepo\rRepository Information\r#\rShow repository information:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.info\rDisplays detailed information about the repository including:\nEndPoint MasterDBSize and DerivedDBSize Number of Datasets, Dataset Revisions, Named Graph Revisions, Commits RepositoryLogs count Whether it\u0026rsquo;s remote Whether it supports revision history Bleve index information Example:\nsst \u0026gt; r1.info\rList Datasets\r#\rList all datasets in the repository:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.datasets\rExample:\nsst \u0026gt; r1.datasets\rGet Dataset by IRI\r#\rGet a dataset by IRI:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.dataset \u0026lt;iri\u0026gt;\rExample:\nsst \u0026gt; r1.dataset urn:uuid:fcfe1293-3045-4717-8065-7dc3659e1faf\rThe dataset is assigned an alias (e.g., d1) for subsequent operations.\nQuery Repository Index\r#\rRun a Bleve text query in the repository index:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.query \u0026lt;bleve-query\u0026gt; [--limit \u0026lt;number\u0026gt;]\rExample:\nsst \u0026gt; r1.query *\rQuery document by UUID:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.queryuuid \u0026lt;uuid\u0026gt;\rExample:\nsst \u0026gt; r1.queryuuid fbe2b5ad-2cc1-4549-a4d4-eb16972ce619\rNote: Both query commands display all indexed fields for each result. The --limit parameter (default: 10) controls how many results are returned.\nList Indexed Fields\r#\rList all indexed fields in the repository:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.listfield\rThis shows all available searchable fields in the Bleve index.\nCommit History\r#\rList commit history:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.log [-v|--verbose]\rUse -v or --verbose for detailed commit information.\nExample:\nsst \u0026gt; r1.log sst \u0026gt; r1.log -v\rShow commit details by hash:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.commitinfo \u0026lt;commit-hash\u0026gt;\rExample:\nsst \u0026gt; r1.commitinfo abc123def456...\rShow commit diff (all changes in a commit):\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.commitdiff \u0026lt;commit-hash\u0026gt;\rThis shows all added/modified/deleted NamedGraphs in the given commit.\nSuperRepository (of a repository)\r#\rShow SuperRepository information for this repository:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.superrepository\rStage Operations\r#\rCreate an empty stage:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.openstage\rThis creates a new empty stage and assigns it an alias (e.g., s1).\nDocument Operations\r#\rList all documents in the repository:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.documents\rShow document metadata:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.documentinfo \u0026lt;hash\u0026gt;\rUpload a document file:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.documentset \u0026lt;file\u0026gt;\rExample:\nsst \u0026gt; r1.documentset /path/to/document.pdf\rDownload a document by hash:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.documentget \u0026lt;hash\u0026gt; \u0026lt;output-file\u0026gt;\rExample:\nsst \u0026gt; r1.documentget abc123... output.pdf\rDelete a document:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.documentdelete \u0026lt;hash\u0026gt;\rInternal Operations (Advanced)\r#\rDump internal BoltDB data (use with caution):\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.dump \u0026lt;bucket-key\u0026gt;[/\u0026lt;sub-key\u0026gt;]\rBucket keys:\nKey Contents ngr NamedGraphRevisions dsr DatasetRevisions c Commits (metadata: author, message, timestamp) ds Datasets (IRI, UUID, etc.) dl DatasetLog (chronological commit log entries) Examples:\nsst \u0026gt; r1.dump ds sst \u0026gt; r1.dump \u0026#34;c/\u0026lt;commit-hash\u0026gt;\u0026#34; sst \u0026gt; r1.dump c\rClone a repository to a local directory:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.clone \u0026lt;target-directory\u0026gt;\rSync data from another repository:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.syncfrom \u0026lt;source-repo-alias\u0026gt; [branch] [dataset1] [dataset2] ...\rExtract raw SST file:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.extractsstfile \u0026lt;hash\u0026gt;\rExtract the raw SST file of a NamedGraphRevision by its hash.\nClose Repository\r#\rClose a repository:\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.close\rThis closes the repository and removes it from the active session.\nDataset Commands\r#\rList Commits\r#\rList commit history starting from each leaf commit (same leaf set as leafcommits, with history traversal):\nsst \u0026gt; \u0026lt;dataset-alias\u0026gt;.listcommits [--details]\rWithout flags, hashes along each chain are shown. Pass --details for full commit information at each step.\nList all branches and their commit hashes:\nsst \u0026gt; \u0026lt;dataset-alias\u0026gt;.branches\rExample output:\nBranches: master: abc123def456... branch1: def456ghi789...\rList all leaf commits (commits not identified by a branch):\nsst \u0026gt; \u0026lt;dataset-alias\u0026gt;.leafcommits\rGet Commit Details\r#\rGet commit details by hash:\nsst \u0026gt; \u0026lt;dataset-alias\u0026gt;.commitsbyhash \u0026lt;hash\u0026gt;\rExample:\nsst \u0026gt; d1.commitsbyhash abc123def456...\rGet commit details by branch:\nsst \u0026gt; \u0026lt;dataset-alias\u0026gt;.commitsbybranch \u0026lt;branch-name\u0026gt;\rExample:\nsst \u0026gt; d1.commitsbybranch master\rBoth commands display:\nCommit Hash Author Date Message Dataset Revisions NamedGraph Revisions Parent Commits Checkout Operations\r#\rCheckout a specific commit:\nsst \u0026gt; \u0026lt;dataset-alias\u0026gt;.checkoutcommit \u0026lt;hash\u0026gt;\rThis creates a new stage from the specified commit. If you do not pass -a, a stage alias is auto-generated (s1, s2, …).\nExample:\nsst \u0026gt; d1.checkoutcommit abc123def456... -a s2\rCheckout a branch:\nsst \u0026gt; \u0026lt;dataset-alias\u0026gt;.checkoutbranch \u0026lt;branch-name\u0026gt;\rThis creates a new stage from the specified branch. Optional stage alias: -a \u0026lt;alias\u0026gt;.\nExample:\nsst \u0026gt; d1.checkoutbranch master sst \u0026gt; d1.checkoutbranch master -a s2\rHistory and Diff\r#\rShow commit history graph:\nsst \u0026gt; \u0026lt;dataset-alias\u0026gt;.history\rThis displays an graph visualization of the commit history.\nCompare two NamedGraphRevision hashes:\nsst \u0026gt; \u0026lt;dataset-alias\u0026gt;.diff \u0026lt;NGR-hash1\u0026gt; \u0026lt;NGR-hash2\u0026gt;\rThis shows the differences between two NamedGraphRevision hashes, including added, modified, and deleted triples.\nExample:\nsst \u0026gt; d1.diff abc123... def456...\rStage Commands\r#\rStage Information\r#\rShow stage information:\nsst \u0026gt; \u0026lt;stage-alias\u0026gt;.info\rDisplays:\nNumber of local graphs Number of referenced graphs Total number of triples IBNodes count for each graph Named Graph Operations\r#\rList named graphs in the stage:\nsst \u0026gt; \u0026lt;stage-alias\u0026gt;.namedgraphs\rList referenced named graphs:\nsst \u0026gt; \u0026lt;stage-alias\u0026gt;.referencednamedgraphs\rGet named graph by IRI:\nsst \u0026gt; \u0026lt;stage-alias\u0026gt;.namedgraph \u0026lt;iri\u0026gt;\rExamples:\nsst \u0026gt; s1.namedgraph urn:uuid:fcfe1293-3045-4717-8065-7dc3659e1faf#\rMerge content from another open stage into this stage (target stage receives graphs from the source):\nsst \u0026gt; \u0026lt;target-stage-alias\u0026gt;.moveandmerge \u0026lt;source-stage-alias\u0026gt;\rValidation\r#\rValidate stage content:\nsst \u0026gt; \u0026lt;stage-alias\u0026gt;.validate\rThis validates the stage content for RDF syntax and domain-range constraints. The output is formatted with clear error and warning sections organized by NamedGraph.\nCommit Changes\r#\rCommit current changes in the stage:\nsst \u0026gt; \u0026lt;stage-alias\u0026gt;.commit \u0026lt;message\u0026gt; [branch]\rExample:\nsst \u0026gt; s1.commit \u0026#34;Initial commit\u0026#34; sst \u0026gt; s1.commit \u0026#34;Updated configuration\u0026#34; feature-branch\rRDF output (stage)\r#\rWrite the stage RDF to a file (TriG):\nsst \u0026gt; \u0026lt;stage-alias\u0026gt;.rdfwrite \u0026lt;file\u0026gt;\rPrint the stage RDF to the console (TriG):\nsst \u0026gt; \u0026lt;stage-alias\u0026gt;.trig\rReading RDF Files\r#\rRead an RDF file in Turtle or TriG format into a new stage:\nsst \u0026gt; rdfread \u0026lt;file\u0026gt;\rExample:\nsst \u0026gt; rdfread /path/to/data.ttl\rThis creates a new stage from the RDF file.\nImport/Export (Converters)\r#\rImport AP242 XML into a new stage:\nsst \u0026gt; importap242xml \u0026lt;file\u0026gt;\rExport a NamedGraph to AP242 XML:\nsst \u0026gt; \u0026lt;namedgraph-alias\u0026gt;.exportap242xml \u0026lt;output-file.xml\u0026gt;\rImport a STEP P21 file into a new stage:\nsst \u0026gt; importp21 \u0026lt;file\u0026gt;\rSuperRepository Commands\r#\rSuperRepositories are opened with openlocalsuperrepository / openremotesuperrepository and get an alias (e.g., sr1).\nCommands:\nsst \u0026gt; \u0026lt;superrepo-alias\u0026gt;.info sst \u0026gt; \u0026lt;superrepo-alias\u0026gt;.close sst \u0026gt; \u0026lt;superrepo-alias\u0026gt;.list sst \u0026gt; \u0026lt;superrepo-alias\u0026gt;.get \u0026lt;repo-name\u0026gt; sst \u0026gt; \u0026lt;superrepo-alias\u0026gt;.create \u0026lt;repo-name\u0026gt; sst \u0026gt; \u0026lt;superrepo-alias\u0026gt;.delete \u0026lt;repo-name\u0026gt;\rNamedGraph Commands\r#\rNamedGraph Information\r#\rShow named graph information:\nsst \u0026gt; \u0026lt;namedgraph-alias\u0026gt;.info\rDisplays detailed information including:\nIRI and ID Whether it\u0026rsquo;s referenced or empty Whether it\u0026rsquo;s modified Number of IRI Nodes, Blank Nodes, Term Collections Number of Direct/All Imported Graphs Number of Subject/Predicate/Object/TermCollection Triples Commit Hash, NamedGraph Revision Hash, Dataset Revision Hash List Nodes\r#\rList all IRI nodes:\nsst \u0026gt; \u0026lt;namedgraph-alias\u0026gt;.foririnodes\rList all IBNodes (IRI nodes and blank nodes):\nsst \u0026gt; \u0026lt;namedgraph-alias\u0026gt;.forallibnodes\rList all blank nodes:\nsst \u0026gt; \u0026lt;namedgraph-alias\u0026gt;.forblanknodes\rGet Node by Fragment\r#\rGet IRINode by fragment:\nsst \u0026gt; \u0026lt;namedgraph-alias\u0026gt;.getirinodebyfragment \u0026lt;fragment-id\u0026gt;\rGet blank node by fragment:\nsst \u0026gt; \u0026lt;namedgraph-alias\u0026gt;.getblanknodebyfragment \u0026lt;fragment-id\u0026gt;\rRDF Output\r#\rWrite RDF to a file (Turtle format):\nsst \u0026gt; \u0026lt;namedgraph-alias\u0026gt;.rdfwrite \u0026lt;file\u0026gt;\rExample:\nsst \u0026gt; ng1.rdfwrite output.ttl\rPrint RDF to console (Turtle format):\nsst \u0026gt; \u0026lt;namedgraph-alias\u0026gt;.ttl\rThis outputs the entire NamedGraph in Turtle format to the console.\nIBNode Commands\r#\rList Triples\r#\rList all triples in an IBNode:\nsst \u0026gt; \u0026lt;ibnode-alias\u0026gt;.forall\rThis displays all triples where the IBNode appears as subject, predicate, or object.\nWorkflow Examples\r#\rExample 1: Basic Repository and Dataset Workflow\r#\r# Open a local repository sst \u0026gt; openlocalrepository /path/to/repo # Check status sst \u0026gt; status # List datasets sst \u0026gt; r1.datasets # Get a dataset sst \u0026gt; r1.dataset urn:uuid:fcfe1293-3045-4717-8065-7dc3659e1faf # View branches sst \u0026gt; d1.branches # Checkout a branch sst \u0026gt; d1.checkoutbranch master # View stage info sst \u0026gt; s1.info # List named graphs sst \u0026gt; s1.namedgraphs # Get a named graph sst \u0026gt; s1.namedgraph urn:uuid:fcfe1293-3045-4717-8065-7dc3659e1faf# # View named graph info sst \u0026gt; g1.info\rExample 2: Reading and Validating RDF\r#\r# Read an RDF file sst \u0026gt; rdfread data.ttl # Validate the stage sst \u0026gt; s1.validate # If valid, commit it sst \u0026gt; s1.commit \u0026#34;Initial data import\u0026#34;\rExample 3: Working with Commits\r#\r# View commit history sst \u0026gt; r1.log -v # Get commit details sst \u0026gt; d1.commitsbyhash abc123... # View history graph sst \u0026gt; d1.history # Compare revisions sst \u0026gt; d1.diff hash1 hash2\rExample 4: Querying and Searching\r#\r# List indexed fields sst \u0026gt; r1.listfield # Run a text query sst \u0026gt; r1.query \u0026#34;field:value\u0026#34; sst \u0026gt; r1.query connector --limit 20 # Query by UUID sst \u0026gt; r1.queryuuid fbe2b5ad-2cc1-4549-a4d4-eb16972ce619\rSee also\r#\rsst.1.md — Git-style command reference (NAME, SYNOPSIS, OPTIONS, full interactive command tables). Exiting\r#\rTo exit the interactive mode, simply type:\nsst \u0026gt; q\rThis will close all opened resources and exit the CLI.\n","externalUrl":null,"permalink":"/sst_core/cli_intro/","section":"SST Core","summary":"","title":"SST-CLI: Introduction to the Command Line Interface","type":"sst_core"},{"content":"SST-Core is an API (software library) for the Golang programming language. It enables the development of high performance Semantic Web applications with a specific extensions based on the SST-Principles to enable the capabilities of the SST-Ontologies.\nDiagram of main application objects\nThe main objects an application has to deal with are:\nRepository: This is either a remote repository somewhere on the Internet or a local one within the same file system where the application is running. For server / cloud applications only remote repositories are used. A remote Repository is identified by a URL, while a local one is defined by a directory path. A repository persistently stores:\nCommits with full history information of all changes of the contained RDF data including who, when, why, and in which branch of the involved Datasets\narbitrary documents (e.g. PDF or images) stored within the repository\nLog: to record all modifications in the Repository\nderived data that is optimised for querying the master data\nDataset: Each represents a persistently stored default NamedGraph together with other directly or indirectly imported NamedGraphs, together with full revision and branch control.\nrevision controlled Datasets; these contain the master information Stage: This is the memory representation of one or several checked-out Dataset Revisions for reading and writing in the form of NamedGraph Revisions.\nNamedGraph:\nIBNode:\nCollections:\nTermCollection: LiteralCollection: Late Binding:\nEarly Binding:\n","externalUrl":null,"permalink":"/sst_core/api/","section":"SST Core","summary":"","title":"SST-Core API","type":"sst_core"},{"content":"SST-Core is available under either a commercial license or under the POLYFORM Noncommercial 1.0.0 license\nKey point: The PolyForm Noncommercial 1.0.0 license prohibits any commercial use, which means:\nSST-Core is not Open Source™ by OSI definition SST-Core is not free software by FSF definition SST-Core is source-available with a usage restriction For commercial licenses contact either:\nSemantic STEP Technology GmbH, Germany, info@semanticstep.com DCT Co., Ltd. Tianjin, China; sst@dct-china.cn The SST-Core sources are available on https://github.com/semanticstep/sst-core\n","externalUrl":null,"permalink":"/sst_core/licenses/","section":"SST Core","summary":"","title":"SST-Core Licenses","type":"sst_core"},{"content":"EDM TBD\n","externalUrl":null,"permalink":"/edm/","section":"SST-EDM Overwiew","summary":"","title":"SST-EDM Overwiew","type":"edm"},{"content":"The SST LCI (Life-Cycle Integration) ontology is derived from the data model as defined in the international standard:\nISO 15926-2:2003 Industrial automation systems and integration —\rIntegration of life-cycle data for process plants including oil and gas production facilities, Part 2: Data model\rThe goal of SST LCI is to support all capabilities of ISO 15926-2, but many things are done in a quite different way. Note that ISO 15926-2 defines a conceptual data model, meaning it is not intended to be a directly implementable data model (even if this is in principle possible as this data model is defined in Express). The SST LCI ontology on the other hand is defined in such a way that it can be directly implemented by most of the available RDF tools. This page highlights the main differences.\n","externalUrl":null,"permalink":"/sst_ontologies/lci_15926-2/","section":"SST Ontologies","summary":"","title":"SST-LCI versus ISO 15926-2","type":"sst_ontologies"},{"content":"Starting point for the development of the SST LCI (Life-Cycle Integration) ontology was the OWL ontology as defined in the international specification:\nISO/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)\nIn the introduction of ISO/TS 15926-12 we can read:\n— \u0026hellip; — This document is an implementation of ISO 15926-2 in OWL in which relationships are object properties, datatype properties or annotation properties. This document defines an ontology that is intended to be used with standard Resource Description Framework (RDF) and OWL tools. The ontology has a partition that is OWL DL and that can support reasoning.\nSome of the content of ISO 15926-2 has not been included in this document, as follows: — \u0026hellip; — approval and status, which are covered by other ontologies and developments within W3C\nThe main high-level differences of SST-LCI to ISO/TS 15926-12 are:\nSST-LCI is not restricted to OWL-DL but takes advantage of OWL-FULL\nin particular SST-LCI relies on Punning where sub-properties are also treated as Individuals; only this allows to cover all the capabilities of ISO 10303-2\nas a result of the above general purpose OWL reasoning on SST data is not suitable and is also not needed as SST requires certain information to be explicitly expressed in SST data\nwith SST-LCI properties (aka characteristics) of things are expresses by RDF Properties for individuals, while ISO 15926 prefers to define classes with the same property value (e.g. the class of all the things that are \u0026ldquo;red\u0026rdquo;)\nSST-LCI refines the concept of rdfs:isDefinedBy in the sub-property lci:isDefinedBy where the domain is another SST-LCI resource (instead of e.g. a web-page for human consumption))\nas a result SST-LCI is much more verbose on the Individual level and removes many of the higher level class concepts from ISO/TS 15926-12\nAs a result about 50% of the terms defined in ISO/TS 15926-12 are directly reflected in the SST LCI ontology, while the other 50% are done somehow differently.\n","externalUrl":null,"permalink":"/sst_ontologies/lci_15926-12/","section":"SST Ontologies","summary":"","title":"SST-LCI versus ISO/TS 15926-12","type":"sst_ontologies"},{"content":"An SST-Repository is the place to store persistent RDF data.\nSST Supports different kinds of SST-Repository for different kinds of needs. Common for all types of SST Repositories is that RDF data is stored in the specific SST-RDF format. The differences are:\nhow SST-RDF data is stored; either as single files or in a BBolt database with or without transaction control when several NamedGraphs are changes simultaneously recording of log information support of GIT like revision control with commit entries support of custom queries via Bleve Index database ","externalUrl":null,"permalink":"/sst_core/repository/","section":"SST Core","summary":"","title":"SST-Repository","type":"sst_core"},{"content":"","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"}]