[{"content":"\rNews\r#\r2026-07-25: SST-EDM MVP (Minimum Viable Product) is released for public access at https://edm.semanticstep.net/. A main highlight that users might to try out is the IEC/ISO 81346 support on Breakdown Systems using RDS - Reference Designation Systems. MVP release means that not all needed functionalities are yet available. Towards the end of 2026 SST-EDM will be available as a full featured product. It will then be available under two licenses:\nfree of charge for small designs and testing without a time limit commercial license with full access and guaranteed memory space 2026-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 80000 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":"Document is one of the main object types in EDM. Information about any number of documents can be recorded in an SST Repository. Main characteristics for a document is its classification to identify the kind of document; here e.g. an International Standard. The classification is customizable\nDetails for the main document\nWithin a main document sub-documents and versioned documents can be defined.\nVarious document properties can be specified; the properties to use are customizable.\n","externalUrl":null,"permalink":"/edm/document/","section":"SST-EDM Overwiew","summary":"","title":"Document","type":"edm"},{"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":"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.\nThe main building components of SST are:\nGeneral constraints on how to use the SemanticWeb standards, especially on the RDF and OWL 2 level. These constraints are the basis that enable high performance implementations.\nThe upper level SST Ontologies that serves as a single level data model covering the whole life-cycle and all major engineering aspects of industrial products\nSST-Core; a speed and memory optimized Semantic Web implementation that takes full advantage of 1.) and 2.) above. This is primarily for software backend developers using Golang. It\u0026rsquo;s main components consist of\nOntologie Compiler if you want to use your own higher level ontologies\nAPI with late- and early binding access methods to analyses and create every kind of RDF data\nSST Repository; either local or Remote for the persistent storage of RDF data in addition to any kind of external documents\nIn combination with SST-Repository GIT like revision control functionality of RDF data enclosed in RDF NamedGraphs and Datasets; this includes branches, diff and merge capabilities\nValidation of RDF data according to the constraints of the higher level ontologies\nSST-CLI: a Command Line Tool to use major SST-Core capabilities without the need to develop an specialized application\nSTEP (ISO 10303) import and export for the so called p21 format (STEP physical files) and STEP-XML\nSST-EDM: An end-user oriented generic tool for Engineering Data Management for many different engineering areas. This tool is currently under development with a first release in mid 2026. Initial application areas are: Classification systems for classes and associated properties\nGeneral PDM capabilities for Parts, Templates, Persons, Organizations, Documents, Quantities \u0026amp; Units, Activities\nBreakdown Structure using IEC/ISO 81346 Reference Designation Systems\nPart Library management using Product Families\nYour Application (free) you might just follow the basic constraints (item 1.) and use the higher level SST Ontologies (item 2.) and use whatever RDF toolkit and application you want and so you can read \u0026amp; write RDF data that conforms to the SST rules.\n(free for noncommercial) or you might develop a Golang application using SS-Core (item 3.)\n(commercial) or you might want to develop you own specific extension to SST-EDM (item 4.)\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":"Overview","summary":"","title":"Overview","type":"overview"},{"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":"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. A NamedGraph is imported into another NamedGraph by the property owl:imports\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":"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 integrated data model. This is in contrast to STEP/ISO 10303 that defines several separated data models that are mapped onto each other: AIM/MIM, ARM, Core Model, Domain Model.\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":"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":"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 the SST-CLI Introduction.\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\nStandalone commands use the first whitespace-delimited token as the command name; remaining tokens are arguments. For alias.command lines, the first token must contain a . (e.g. r1.info); the part before the first . is the alias, the part after is the subcommand and its arguments (parsed with quote-aware splitting).\nCase\nStandalone keywords such as help are matched case-insensitively. 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). sstread file Load an SST binary file into a new stage (new alias). importap242xml file Import AP242 XML into a new stage. importp21 file [-o raw-ttl] Import STEP P21 into a new stage; use -o to write pre-conversion raw Turtle for debugging. 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. 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. checkoutcommit hash [-a stage-alias] Materialize a stage at a repository commit (all NamedGraphs affected by the commit). 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. commitdetailsbyhash hash Show commit details by hash. commitdetailsbybranch branch Show commit details by branch. branches List branches and commit hashes. leafcommits List leaf commit hashes only. checkoutcommit hash [-a stage-alias] Materialize a stage at a commit (single dataset scope). checkoutrevision hash [-a stage-alias] Materialize a stage at a dataset revision. checkoutbranch branch [-a stage-alias] Materialize a stage at a branch tip. setbranchcommit commit-hash branch Set a branch to point to a commit. setbranchrevision dataset-revision-hash branch Set a branch to point to a dataset revision. removebranch branch Remove a branch from the dataset. 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. alignhistory from-stage-alias Copy repository pointer and checkout metadata from from-stage-alias onto this stage (e.g. after external RDF edit and rdfread). Does not merge triples or unregister the source stage. commit message [branch] Commit staged changes. validate [-o file] RDF / domain-range validation; print report to console, or write to file with -o (default extension .txt). rdfwrite file Write stage as TriG. trig Print stage TriG to stdout. writesstfilesdirectory directory Write modified NamedGraphs as SST binary files into directory. 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. sstwrite file Write SST binary 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#\r.env.sst-cli (gitignored, local only)\nLoaded at startup from ./.env.sst-cli or $HOME/.env.sst-cli. Shell variables already set are not overwritten.\nFile format\nOne variable per line: KEY=VALUE Empty lines and lines starting with # are ignored Values may be double- or single-quoted: KEY=\u0026quot;value\u0026quot; Required (remote repository authentication)\nVariable Format SST_OIDC_REALM_URL Keycloak realm base URL, no trailing slash (e.g. https://host/auth/realms/users) SST_OIDC_CLIENT_ID OAuth client id (non-empty string) SST_OIDC_CLIENT_SECRET OAuth client secret (non-empty string) Optional\nVariable Format SST_USERNAME Keycloak username; used only if SST_PASSWORD is also set SST_PASSWORD Keycloak password; used only if SST_USERNAME is also set If either SST_USERNAME or SST_PASSWORD is missing, the CLI prompts interactively. 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#\rSST-CLI Introduction — 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.commitdetailsbyhash \u0026lt;hash\u0026gt;, d1.history, d1.checkoutbranch \u0026lt;branch\u0026gt;, d1.setbranchcommit \u0026lt;hash\u0026gt; \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 *\rNote: The query command displays 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.\nCheckout a repository commit into a stage (all NamedGraphs affected by that commit):\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.checkoutcommit \u0026lt;commit-hash\u0026gt; [-a \u0026lt;stage-alias\u0026gt;]\rExample:\nsst \u0026gt; r1.checkoutcommit abc123def456... -a s2\rUnlike \u0026lt;dataset\u0026gt;.checkoutcommit, this loads every NamedGraph recorded in the commit without requiring a dataset alias first.\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;.commitdetailsbyhash \u0026lt;hash\u0026gt;\rExample:\nsst \u0026gt; d1.commitdetailsbyhash abc123def456...\rGet commit details by branch:\nsst \u0026gt; \u0026lt;dataset-alias\u0026gt;.commitdetailsbybranch \u0026lt;branch-name\u0026gt;\rExample:\nsst \u0026gt; d1.commitdetailsbybranch master\rBoth commands display:\nCommit Hash Author Date Message Dataset Revisions NamedGraph Revisions Parent Commits Checkout Operations\r#\rCheckout a repository commit (all NamedGraphs in the commit):\nsst \u0026gt; \u0026lt;repo-alias\u0026gt;.checkoutcommit \u0026lt;hash\u0026gt; [-a \u0026lt;stage-alias\u0026gt;]\rThis creates a new stage from the specified repository commit. Use this when you have a commit hash from repo.log or repo.commitinfo and need a stage containing all datasets/NamedGraphs affected by that commit.\nExample:\nsst \u0026gt; r1.checkoutcommit abc123def456... -a s2\rCheckout a specific commit (single dataset):\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 specific dataset revision:\nsst \u0026gt; \u0026lt;dataset-alias\u0026gt;.checkoutrevision \u0026lt;hash\u0026gt;\rThis creates a new stage from the specified dataset revision hash. Use this when a dataset revision exists that is not associated with a branch name. If you do not pass -a, a stage alias is auto-generated (s1, s2, …).\nExample:\nsst \u0026gt; d1.checkoutrevision 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\rBranch Management\r#\rSet a branch to point to a commit:\nsst \u0026gt; \u0026lt;dataset-alias\u0026gt;.setbranchcommit \u0026lt;commit-hash\u0026gt; \u0026lt;branch-name\u0026gt;\rExample:\nsst \u0026gt; d1.setbranchcommit abc123def456... feature\rSet a branch to point to a dataset revision (when the revision is not tied to a commit lookup):\nsst \u0026gt; \u0026lt;dataset-alias\u0026gt;.setbranchrevision \u0026lt;dataset-revision-hash\u0026gt; \u0026lt;branch-name\u0026gt;\rExample:\nsst \u0026gt; d1.setbranchrevision def456ghi789... feature\rRemove a branch:\nsst \u0026gt; \u0026lt;dataset-alias\u0026gt;.removebranch \u0026lt;branch-name\u0026gt;\rExample:\nsst \u0026gt; d1.removebranch feature\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;\rAlignHistory (replace data, keep checkout history)\r#\rCopy the repository link and per–named-graph checkout metadata (commit, NG revision, DS revision) from an existing checkout stage onto another stage—typically a stage produced by rdfread after you edited TriG/Turtle outside SST. Unlike moveandmerge, this does not merge graph contents or remove the source stage from the session; it only aligns history so a subsequent commit from the target stage can record changes against the same repository lineage.\nsst \u0026gt; \u0026lt;to-stage-alias\u0026gt;.alignhistory \u0026lt;from-stage-alias\u0026gt;\rto-stage: Stage with the new RDF content (often from rdfread; it may not be linked to a repository before this command). from-stage: Original checkout stage; must already be linked to a repository. Typical flow: checkout → rdfwrite → edit file externally → rdfread (new stage) → \u0026lt;new\u0026gt;.alignhistory \u0026lt;original\u0026gt; → commit on the new stage.\nValidation\r#\rValidate stage content:\nsst \u0026gt; \u0026lt;stage-alias\u0026gt;.validate sst \u0026gt; \u0026lt;stage-alias\u0026gt;.validate -o \u0026lt;file\u0026gt;\rThis validates the stage content for RDF syntax and domain-range constraints. Without -o, the detailed report is printed to the console (organized by NamedGraph, with each finding showing the message and the related triple). With -o \u0026lt;file\u0026gt;, the full report is written to a file; if the path has no extension, .txt is appended automatically.\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\rSST file output (stage)\r#\rWrite modified NamedGraphs from a stage into a directory as SST binary files\nsst \u0026gt; \u0026lt;stage-alias\u0026gt;.writesstfilesdirectory \u0026lt;directory\u0026gt;\rExample:\nsst \u0026gt; s1.writesstfilesdirectory ./out-sst\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.\nReading SST Files\r#\rRead an SST binary file into a new stage:\nsst \u0026gt; sstread \u0026lt;file\u0026gt;\rExample:\nsst \u0026gt; sstread /path/to/data.sst\rThis creates a new stage from the SST file. Use \u0026lt;stage\u0026gt;.namedgraph \u0026lt;iri\u0026gt; to obtain a NamedGraph alias, then \u0026lt;namedgraph\u0026gt;.sstwrite \u0026lt;file\u0026gt; to write it back to SST binary.\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\rWrite SST binary to a file:\nsst \u0026gt; \u0026lt;namedgraph-alias\u0026gt;.sstwrite \u0026lt;file\u0026gt;\rExample:\nsst \u0026gt; ng1.sstwrite output.sst\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.commitdetailsbyhash 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\rSee also\r#\rSST-CLI Reference — 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. Many of the SST-Core methods and functions are available in the Command Line Interface tool SST-CLI.\nAll functions and methods of SST-Core can be divided into two groups:\nthe ones that operates on the persistent data storage in a Repository (left side of the diagram) and the ones that operates on data in memory within a Stage (right side of the diagram). Repository\r#\rA Repository is either a remote repository somewhere on the Internet or one in a local file system accessible to the SST application. 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. All access to a remote Repository requires a GO-Context parameter that encodes the identity and access rights of the user. An SST Repository is a persistent storage consisting of 3 main component:\nBBolt which is an embedded, serialisable, transactional key/value database, able to manage huge amounts of data. BBolt is used to store the master data, consisting of RDF Datasets and NamedGraphs with full GIT like revision control capabilities including Commits, Logs, Branches / Revisions. In addition it also contains Document meta information\nBleve that is an embedded search engine that uses Lucene-style full-text search and indexing capabilities. The Bleve index contains derived data from the master data. The purpose of splitting into master data and derived data is to achieve high loading/saving speed of master data in combination with customisable query capabilities to be able to serve very many Datasets / NamedGraphs.\nDocument Vault is used to store any kinds of non-RDF Documents (e.g. images or PDF files) that an application might need in combination with RDF data.\nDataset: A Dataset represents a persistently stored default NamedGraph together with other directly or indirectly imported NamedGraphs, using owl:imports within a Repository. A Dataset and the corresponding default NamedGraph share the same base IRI. Note that these IRIs contain NO fragment. A particular Dataset is located within a Repository by the Repository method Dataset(dataset-IRI). A Repository might contain many Revisions or Named-Branches of a Dataset. They are accessible by the Dataset methods CheckoutBranch, CheckoutRevision or CheckoutCommit.\nNamedGraph-Revision: All NamedGraph-Revisions are encoded within the Repository using the SST file format. From the resulting BLOB (Binary Large Object) the HASH256 value is calculated and used as NamedGraph-Revision index and the BLOB itself as value for an index-value pair in the BBolt database. In a similar way a Dataset-Revision is calculated from the default.NamedGraph and the HASH values of the Datasets of the corresponding NamedGraph that are directly imported\nDataset-Revision: This is identified by another HASH256 value that is calculated from the HASH value of the corresponding default NamedGraph-Revision and the HASH values of all other directly and indirectly imported NamedGraphs. By this all directly and indirectly imported NamedGraphs are under full revision control of the Dataset. Other NamedGraphs that are referenced but not imported are not under revision control.\nCommit: A Stage that is linked to a Repository and that contains either new or modified NamedGraph can be committed to the linked Repository; resulting into a new Commit entry and new Dataset-Revisions and in most cases new NamedGraph-Revisions. In addition a Commit contains a comment that should describe the kind of changes, the person who performed the commit and a timestamp. All this together results into a Commit-HASH256 that identifies the Commit.\nBranch: A named Revision of a Dataset. Note that each Dataset can have it\u0026rsquo;s own Branch names. Branch names are not automatically harmonised between the Datasets of a Repository.\nStage\r#\rA Stage is an in memory representation of one or several NamedGraph and their interlinked Triples. A Stage might or might not be linked to a Repository into which changes might be committed. A Stage is create by either Checkout a Dataset-Revision from a Repository, creating a new empty one, or importing a Turtle, Trig, SST or other kind of file. A Stage can contain main NamedGraphs, but each one in a single revision only. The content of a Stage can be moved and merged into another Stage. A Stage can be aligned with another Stage that is linked with a repository and that contains NamedGraph revisions that require update.\nNamedGraph: This is an in-memory representation of an RDF NamedGraph that is either in Local or in Referenced state: A Local NamedGraph contains all the IBNodes that are \u0026ldquo;owned\u0026rdquo; by this NamedGraph and all their Subject Triplexes. A Local NamedGraph might directly import other Local NamedGraphs. On the other hand a Reference NamedGraph contains only those IBNodes that are referenced by other Local NamedGraph and contains no Subject Triplexes.\nIBNode: This is either an IRI-node or a blank-node. For SST an IBNode is owned by exactly one NamedGraph; the NamedGraph that has the same base-IRI as it\u0026rsquo;s IBNodes. The IBNodes in a NamedGraph must all have different Fragments. There is one special IBNode in each NamedGraph that has an empty/no fragment and that represents the containing NamedGraph as a whole. This special IBNode is always of type owl:Ontology.\nCollections: The term Collection is defined/used in Turtle and is a more compact way to represent rdf:Lists. Formally rdf:Lists are treated as blank nodes, but for optimisation reasons SST has defined special object types for these:\nLiteralCollection: They contain only literals that are all of the same Datatype. TermCollection: These are for all other collections, including those with IBNodes, and nested Collections Triple: or RDF Statement consisting of a Subject, a Predicate and an Object. The Triples an IBNode is involved in are accessible by the IBNode method ForAll(). It will show up Triples in up to 3 different variants that are called Subject Triplex, Predicate Triplex and Object_Triplex, depending on whether this IBNode is used as subject, predicate or object.\nTriplex: This defines the direction in which triples can be analysed by an application:\na Subject Triplex starts from a Subject IBNode and leads to a Predicate and Object Node/Literal; this is always available a Predicate Triplex starts from a Predicate IBNode and leads to a Subject and Object Node/Literal; this is optional an Object Triplex starts from an Object IBNode and leads to a Subject and Predicate Node; this is optional A Stage has a Mode parameter that controls which Triplexes are supported within this Stage.\n","externalUrl":null,"permalink":"/sst_core/api/","section":"SST Core","summary":"","title":"SST-Core API","type":"sst_core"},{"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 TriG: An extension of Turtle suporting several NamedGraphs 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 : A Commit Operation creates a Commit Record in an SST Repository. A Commit Record is identified by a Hash value. The Commit Operation writes modified NamedGraphs 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 : An RDF statement consisting of a subject Node, a predicate Node or an object Term.\nTerm : A Term is either a Literal, a LiteralCollection, or a Node.\nTerm ├── Literal ├── LiteralCollection └── Node ├── IBNode └── TermCollection\rNode : A Node is either an IBNode or a LiteralCollection.\nIBNode : Using RDF terms, an IBNode is either an IRI node, or a blank node. Note that SST supports also the Terms LiteralCollections and TermCollection that are not IBNodes (see below).\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 : Literals are values of a Datatype; the following Datatypes are supported by SST:\nxsd:string : GO string rdf:langString : GO type TypedString struct { Val string, Type Node } xsd:boolean : GO bool xsd:decimal : uses string representation xsd:integer : GO int64 xsd:double : GO float64 xsd:float : GO float32 xsd:dateTime : GO string xsd:dateTimeStamp : GO string xsd:byte : GO int8 xsd:short : GO int16 xsd:int : GO int32 xsd:long : GO int64 xsd:unsignedByte : GO uint8 xsd:unsignedShort : GO uint16 xsd:unsignedInt : GO uint32 xsd:unsignedLong : GO uint64 TermCollection : An RDF collection that is an ordered list of RDF nodes or literals. A TermCollection can also contain other TermCollections 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 TermCollections 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; see RFC 6749 - The OAuth 2.0 Authorization Framework\nOIDC : Open ID Connect, an authentication layer on top of the OAuth 2.0 authorization framework.\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":"SST-Core concepts and terms","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":"\rOverview\r#\rWhen talking about STEP data models we have to make clear on which particular level of data model we are talking about. There are:\nthe Integrated Model (IM) based on the STEP Integrated Resources (IR: 40, 100 and 500 series) and the Application Integrated Model (AIM: 200) respectively the Modular Integrated Model (MIM: 400 and 1000 series). This model is used for data exchange in a STEP p21 file. The Application Reference Model (ARM: 200, 400 and 1000 series) that is not intended to be directly implemented (but had been in a few cases) The Core Model (part 4000) whose purpose is to better facilitate the mapping between the Domain Model and the ARM The Domain Model ( 4000 series except part 4000 itself) in SysML that is used for STEP XML data exchange. All these model cover the same application area and are in fact similar; but because of different terminology and different levels of details mappings are needed. The following mappings are defined:\nfrom Domain Model to the Core Model from Core Model to the ARM from the ARM to the AIM/MIM The STEP architecture indicated above is very different to the one used in SST. All SST Ontologies define together a single level integrated implementation data model that is directly used for data exchange such as Turtle, TriG, Json-LD and also within the SST Repositories.\nFor converting STEP data to SST the following ontologies defined earlier are used:\nssmeta: this defined directives for the generic convertion between STEP data and SST data lci: that contains generic concepts such as lci:Organization and lci:Person qau: that defines Quantities and Units replacing the STEP 10303-41 definitions of the measure_schema The specific STEP ontologies are:\nrep: based on the ISO 10303-43 Representation structures and all the extension of this for e.g. geometry, topology, kinematics, presentation and many more. The rep ontology is strictly derived from the Express models of the corresponding IM/IR parts. sso: for all other STEP definitions that are not covered by the rep ontology; this includes all Product Data Management (PDM), configuration control, assembly, breakdown and many more areas. The sso ontology is primarily based on the Domain Model, but also covers several MIM constructs as well. General Concepts\r#\rSimple Express entity that maps to an owl:Class\r#\rA typical Express entity, resp. SysML class maps to a corresponding OWL class, that is a specializations of one of the lci classes. Explcit entity attributes in STEP maps to OWL properties. Derived, redeclared-as-derived and inverse attributes are not mapped.\nExample:\nENTITY cartesian_point SUPERTYPE OF (ONEOF (cylindrical_point, polar_point, spherical_point)) SUBTYPE OF (point); coordinates : LIST[1:3] OF length_measure; END_ENTITY;\rThe usage within a STEP p21 file looks like this\n#1234=CARTESIAN_POINT(\u0026#39;\u0026#39;,(-65.3628370504986,-69.,-41.6407196468788));\rEntity cartesian_point maps to a corresponding owl:Class rep:CartesianPoint and the entity attribute coordinates to a corresponding owl property rep:coordinates. While the entity attribute coordinates is dependent on the enclosing entity cartesian_point (so a second class citensence) the corresponding owl property rep:coordinates ist defined independently and thus could be extended for a more general purpose (by extending the rdfs:domain)\nrep:CartesianPoint ssmeta:stepImEntityMap \u0026#34;cartesian_point\u0026#34; ; a owl:Class , ssmeta:MainClass ; rdfs:subClassOf rep:Point ; ssmeta:stepImMapAttributeOrder ( :coordinates ) . sh:closed true ; sh:ignoredProperties (rdf:type) ; sh:property [ sh:path :coordinates ; sh:name \u0026#34;CartesianPoint.coordinates\u0026#34; ; sh:minCount 1 ; sh:maxCount 1 ] . rep:coordinates ssmeta:stepImAttributeMap \u0026#34;cartesian_point.coordinates\u0026#34; ; a owl:ObjectProperty , owl:FunctionalProperty ; rdfs:domain :CartesianPoint ; rdfs:range :ListOfDouble . This is used within a Turtle file like this:\n:uuid99 a rep:CartesianPoint ; rep:coordinates ( -65.3628370504986 -69.0 -41.6407196468788 ) .\rSimple Express entity that maps to an owl property\r#\rIn STEP we can find many entities that are named xxx_relationship or xxx_assignment.\nThese entities have no semantic by themselves - they are just syntax - and are therefor\n","externalUrl":null,"permalink":"/sst_ontologies/step/","section":"SST Ontologies","summary":"","title":"STEP Ontologies","type":"sst_ontologies"},{"content":"","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"}]