|
Note
|
Compared to IFC-LD v0.1, this release:
|
1. Rationale
IFC-LD is a data model and family of serializations designed to support the exchange of information about the built environment. It is interoperable with all existing versions of IFC, while embracing new directions. Practically, IFC-LD aims to "rebase" IFC on linked data, allowing the community to shed its dependency on ISO 10303, including the P21 ("STEP") instance format and EXPRESS schema language. Unlike ifcOWL, IFC-LD provides full support for closed-world schema definition and validation via the SHACL constraint language.
IFC-LD attempts to solve several problems with IFC-based data exchanges:
-
To avoid use of custom parsers for ISO 10303-21 ("P21") files, IFC-LD defines a trivial instance data model based on the Resource Description Framework (RDF). IFC-LD instance data may be exchanged using any RDF-compatible serialization.
-
To avoid the need for bespoke data validation tools, IFC-LD replaces EXPRESS with SHACL as the de facto encoding of the IFC schema. Given a SHACL-encoded snapshot of the IFC schema, and an IFC-LD instance population, users can validate the instance population against the schema using any SHACL processor. Users may create their own SHACL definitions to extend IFC, similar to what they do today with IDS.
-
To support composition, all IFC schema and instance data are treated as independent assets, linked by URIs.
Rebasing IFC on a minimal but complete set of linked data standards is what allows IFC-LD to integrate all existing IFC schemas while supporting new directions.
2. Goals
2.1. Data Addressability
All exchanged data must be unformly addressable, because linking or referencing data requires it have a name. Given the distributed, global nature of the built environment, the most natural namespace for built assets is the web, where shared assets are addressable by URIs.
2.2. Interoperability with ISO 10303
The vast majority of the world’s existing IFC data is encoded as ISO 10303-21 files. It is also the primary serialization existing commercial systems support. To encourage broad adoption of IFC-LD, and to ensure we can migrate existing asset data, interoperability with the Part 21 exchange format is required. Likewise, the EXPRESS encoding of the IFC schema must be replaced with one of equal of greater expressive power.
2.3. Serialization-Agnosticism
Data serializations are tailored towards specific access patterns. As the access patterns for IFC data are open-ended, and IFC intends to be used by many stakeholders over long periods of time, its encoding must remain agnostic to maximize integration and extension opportunities as the software landscape evolves.
2.4. Extensibility
The IFC-LD specification cannot anticipate every need. Instead, it must provide a small set of capabilities that could later be extended. Rather than inventing these extension capabilities from scratch, it can leverage those it builds upon (i.e., RDF, SHACL).
2.5. Minimal Inventiveness
IFC-LD aims to be defined purely in terms of existing ontologies, data models, and standards. No bespoke technologies or data formats should be required for its implementation.
The challenge is to transform the current standards and solutions towards more generic technology bases. This is needed to create the necessary scalability and broaden adoption.
3. Design
3.1. Instances
IFC-LD maps P21 instance features directly to RDF, supporting near-lossless conversion between the two. A complete description of the mapping can be found in P21 to IFC-LD Instance Mappings. In summary:
-
Each P21 instance file is translated to an RDF named graph.
-
P21 file metadata become property-value pairs on the named graph.
-
P21 instances become RDF resources. Each instance is assigned a URI by treating its P21 instance number (e.g.,
#21) as a relative URI to the base URI of the exchange file. -
P21 instance properties are indexed by name (e.g.,
owningapplication), taken from the IFC-LD SHACL schema during conversion. -
P21 instance types (e.g.,
ifcapplication) are converted to the equivalent rdf:type relation. -
P21 literals become RDF resources with property rdf:value.
NoteIFCDAYINWEEKNUMBER(6)is a valid IFC-STEP structured value, so
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix ifc: <http://ifc-ld.org/schemas/ifc2x3#> . [] a ifc:dayofweeknumber ; rdf:value 6 .is a valid IFC-LD structured value.
This approach also allows IFC-LD values to carry arbitrary metadata (e.g., about who declared them or which contexts they are relevant in).
By convention, all IFC-LD type and property names are encoded in lowercase.
Example P21 instances and their IFC-LD equivalents can be found in IFC-LD Instance Examples.
3.2. Schemas
To fulfill its Goals, IFC-LD must adopt a schema language that is:
-
at least as expressive as EXPRESS, including support for types, relations, and closed-world validation
-
serialization-agnostic
-
capable of supporting integration with domain-adjacent data models
SHACL fulfills these requirements, providing a rich schema language backed by a W3C standard with both open and commercial tooling support.
All EXPRESS constructs used in IFC can be encoded in SHACL. Where there is ambiguity, IFC-LD follows these heuristics:
-
Treat all structural parts of the IFC schema as first-class. This maximizes reuse because the same definition (e.g., of a particular property, like
owningapplication) can be reused across the schema without duplication. This reduces the size of the schema and cognitive load on those who need to learn it. -
Treat all values as structured values. This increases the size of serialized instances, but allows schema definitions to be reused across different contexts. It also lets instance values be treated as resources, allowing them to carry additional metadata (e.g., who asserted them, and why).
-
Use logical operations (e.g.,
sh:and,sh:xone) to model schema composition and selection. Formal inheritance hierarchies are replaced by independent schema definitions joined by logical operations.
Given an IFC-LD instance population and the SHACL encoding of the corresponding IFC schema, the population can be validated against the schema using any conforming SHACL processor. No custom tooling, intermediary data format, or centralized validation service is required.
| Express | SHACL |
|---|---|
Entity |
|
Entity Property |
sh:NodeShape (Properties become first-class structured values) |
Abstract Entity |
dash:abstract flag |
Entity Inheritance |
|
Types |
sh:NodeShape targeting an rdf:value structured value |
Enumerations |
sh:PropertyShapes targeting sh:in |
Selects |
sh:NodeShape targeting sh:xone |
Where Rules |
|
Functions |
Example mappings from IFC-EXPRESS schema definitions to their IFC-LD SHACL equivalents are given below.
3.2.1. Schema Mapping : Types
TYPE IfcInductanceMeasure = REAL;
END_TYPE;ifc:ifcinductancemeasure
a sh:NodeShape ;
sh:property [
sh:datatype xsd:double ;
sh:maxCount 1 ;
sh:minCount 1 ;
sh:path rdf:value
] ;
sh:targetClass ifc:ifcinductancemeasure .3.2.2. Schema Mapping : Selects
TYPE IfcMaterialSelect = SELECT
(IfcMaterialDefinition
,IfcMaterialList
,IfcMaterialUsageDefinition);
END_TYPE;ifc:ifcmaterialselect
a sh:NodeShape ;
sh:xone (ifc:ifcmaterialdefinition
ifc:ifcmateriallist
ifc:ifcmaterialusagedefinition
) .3.2.3. Schema Mapping : Enumerations
TYPE IfcReinforcingMeshTypeEnum = ENUMERATION OF
(USERDEFINED
,NOTDEFINED);
END_TYPE;ifc:ifcreinforcingmeshtypeenum
a sh:NodeShape ;
sh:property [
sh:datatype xsd:string ;
sh:in ("notdefined"
"userdefined"
) ;
sh:maxCount 1 ;
sh:minCount 1 ;
sh:path rdf:value
] ;
sh:targetClass ifc:ifcreinforcingmeshtypeenum .3.2.4. Schema Mapping : Entities
ENTITY IfcFillAreaStyleTiles
SUBTYPE OF (IfcGeometricRepresentationItem);
TilingPattern : LIST [2:2] OF IfcVector;
Tiles : SET [1:?] OF IfcStyledItem;
TilingScale : IfcPositiveRatioMeasure;
END_ENTITY;ifc:ifcfillareastyletiles
a sh:NodeShape ;
sh:and (ifc:ifcgeometricrepresentationitem
) ;
sh:name "ifcfillareastyletiles"@en ;
sh:property ifc:tiles, ifc:tilingpattern, ifc:tilingscale ;
sh:targetClass ifc:ifcfillareastyletiles .3.2.5. Schema Mapping : Properties
ifc:tiles
rdf:ordered false ;
a sh:PropertyShape ;
sh:minCount 1 ;
sh:name "tiles"@en ;
sh:node ifc:ifcstyleditem ;
sh:path ifc:tiles .ifc:tilingpattern
rdf:ordered true ;
a sh:PropertyShape ;
sh:maxCount 1 ;
sh:minCount 1 ;
sh:name "tilingpattern"@en ;
sh:node dash:ListShape ;
sh:path ifc:tilingpattern ;
sh:property [
sh:maxCount 2 ;
sh:minCount 2 ;
sh:node ifc:ifcvector ;
sh:path ([
sh:zeroOrMorePath rdf:rest
]
rdf:first
)
] .ifc:tilingscale
a sh:PropertyShape ;
sh:maxCount 1 ;
sh:minCount 1 ;
sh:name "tilingscale"@en ;
sh:node ifc:ifcpositiveratiomeasure ;
sh:path ifc:tilingscale .For the IFC-LD SHACL encodings of existing IFC versions, see IFC SHACL Schema Definitions.
3.3. Integration
IFC-LD applies SHACL Rules in a standard pattern to support integration with domain-adjacent data models and ontologies. SHACL Rules may be written for any target ontology, by any number of stakeholders, and only assumes the availability of a SHACL Rules processor and input IFC-LD dataset. SHACL Rules support arbitrary rewriting of the IFC-LD graph, supporting data integration not practical with other approaches.
#@prefix ifc: <http://ifc-ld.org/schemas/ifc2x3#> .
@prefix mod: <http://ifc-ld.org/profiles/bot/ifc2x3#> .
@prefix bot: <https://w3id.org/bot#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
bot:
sh:declare [
sh:prefix "bot" ;
sh:namespace "https://w3id.org/bot#"^^xsd:anyURI ;
] .
mod:BotHasBuildingRule
a sh:NodeShape ;
sh:targetClass ifc:ifcsite ;
sh:rule [
a sh:SPARQLRule ;
sh:prefixes rdf: ;
sh:prefixes bot: ;
sh:prefixes ifc: ;
sh:construct """
CONSTRUCT {
?site bot:hasBuilding ?building .
} WHERE {
?site rdf:type ifc:ifcsite .
?relaggregates rdf:type ifc:ifcrelaggregates .
?relaggregates ifc:relatingobject ?site .
?relaggregates ifc:relatedobjects ?building .
}
""" ;
]
.
mod:BotHasStoreyRule
a sh:NodeShape ;
sh:targetClass ifc:ifcbuilding ;
sh:rule [
a sh:SPARQLRule ;
sh:prefixes rdf: ;
sh:prefixes bot: ;
sh:prefixes ifc: ;
sh:construct """
CONSTRUCT {
?building bot:hasStorey ?storey .
} WHERE {
?building rdf:type ifc:ifcbuilding .
?relaggregates rdf:type ifc:ifcrelaggregates .
?relaggregates ifc:relatingobject ?building .
?relaggregates ifc:relatedobjects ?storey .
?storey rdf:type ifc:ifcbuildingstorey .
}
""" ;
]
.
mod:BotHasSpaceRule
a sh:NodeShape ;
sh:targetClass ifc:ifcbuildingstorey ;
sh:rule [
a sh:SPARQLRule ;
sh:prefixes rdf: ;
sh:prefixes bot: ;
sh:prefixes ifc: ;
sh:construct """
CONSTRUCT {
?storey bot:hasSpace ?space .
} WHERE {
?storey rdf:type ifc:ifcbuildingstorey .
?relaggregates rdf:type ifc:ifcrelaggregates .
?relaggregates ifc:relatingobject ?storey .
?relaggregates ifc:relatedobjects ?space .
?space rdf:type ifc:ifcspace .
}
""" ;
]
.Other target ontologies, like BrickSchema, may be integrated into the IFC-LD ecosystem by writing the appropriate SHACL Rules.
3.4. Extension
IFC-LD’s design inherits from RDF the benefits of associativity. Practically, this means:
-
An IFC-LD graph can be divided into multiple independent subgraphs without loss of information. Conversely, independent IFC-LD subgraphs can composed into a new graph representing their union. This can be done using standard RDF tooling and is particularly useful for use cases where aspects of a built assets are owned by different parties.[1]
Two geographically isolated stakeholders, Alice and Bob, can each make declarations about the same built asset.
alice_model:52 a ifc:buildingstorey;
ifc:globalid [ rdf:value "1s5utE$rDDfRKgzV6jUJTg"];
ifc:name "S1-F1"bob_model:180 a ifc:buildingstorey;
ifc:globalid [ rdf:value "1s5utE$rDDfRKgzV6jUJTg"];
ifc:description "Floor 1"The two sets of declarations can be composed by querying against their common "Global ID",
CONSTRUCT {
?entity ?property ?value
} WHERE {
?component ifc:globalid ?sval .
?sval rdf:value ?globalId .
BIND (URI(CONCAT("http://ifc-ld.org/ids#",?globalId) AS ?entity)) .
?component ?property ?value .
} Returning
<http://ifc-ld.org#1s5utE$rDDfRKgzV6jUJTg>
a ifc:buildingstorey;
ifc:globalid [ rdf:value "1s5utE$rDDfRKgzV6jUJTg"];
ifc:name "S1-F1" ;
ifc:description "Floor 1" .-
IFC-LD schema definitions can be extended by stakeholders to add context-specific validation requirements. Instead of distinct schema languages for the IFC schema (EXPRESS) and its bespoke, context-specific extensions (IDS), the same open schema language, SHACL, can be used for both.
[We need to] move from bespoke solutions and technology to generic technologies and solutions that are scalable, widely adopted and work in a broad range of tools.
ifc:version sh:node acme:supported_versions triple declaration to a secondary schema, a SHACL validator will check that every IfcApplication version property instance conforms to the custom acme:supported_versions NodeShape and not just ifc:ifclabel defined by IFC.
3.5. Roadmap
At the time of writing, the following IFC-LD tools are reaching MVP status:
-
A one-way EXPRESS to IFC-LD SHACL compiler, based on NIST’s STEPCode.
-
A one-way P21 to IFC-LD instance compiler, available with both CLI and HTTP interfaces. Bidirectional conversion and compilation to secondary formats is next.
All schemas and examples included in this specifications were generated with these tools. Publication of those tools, potentially as part of a "playground", is an area of active work.
IFC-LD’s ability to interoperate with adjacent data models (as shown in Integration) should be taken further. Particularly useful projects include:
-
A one-way IDS to SHACL compiler
-
A one-way set of SPARQL transformations from IFC-LD to brick.
With the baseline IFC-LD schema and modeling methodology established, stronger refactoring of the IFC schema itself can start productively. Easy places to start include:
-
removing property definitions
-
reducing the inconsistent use of (nested) lists
-
writing transformations to adjacent data models that would allow us to deprecate specific IFC entities (e.g., deprecating IfcOwnerHistory in favor of the PROV model).
-
writing tranformations to produce software SDKs directly from IFC-LD schema definitions.
IFC-LD encourages a built asset ecosystem where:
-
shared asset information can be encoded in long-lived, wire-agnostic, open standards.
-
tooling for those standards can be built by the community, and containerized for flexible deployment.
-
vendors align their internal data models to those supported by (or derived from) IFC-LD, and otherwise focus on providing differentiated user experiences to their users.
4. References
4.1. FAQs
4.1.1. How much do I need to know about linked data to use IFC-LD?
Very little. Unless you have a desire to write new schema definitions, or tinker with instance files by hand, no knowledge of RDF, SHACL, or adjacent technologies is necessary. IFC-LD expects the majority of stakeholders will interact with IFC(-LD) through their authoring environments.
Stakeholders wishing to extend IFC-LD, or add new rules for particular use cases, will benefit from learning the basics of the RDF data model, and aspects of SHACL schema language built on top of it. This can be done incrementally, and tooling and templates can be provided to support efficient learning.
4.1.2. How does IFC-LD compare to ifcOWL?
IFC-LD is Like ifcOWL in that it is:
-
based on linked data
-
interoperable (to different degrees) with the existing IFC schema
IFC-ID differs from ifcOWL in that it does not:
-
does not model EXPRESS schema concepts explictly, but instead translates them into their modern SHACL equivalents.
-
encourages use of "closed-world" schema validation over "open-world" inferencing, at least for common use cases. Schema languages like SHACL are more familiar to stakeholders than OWL’s description logics.
IFC-LD tries to package the power of linked data in a framework that’s approachable and open-ended.
4.1.3. Why does IFC-LD recommend schema definitions be defined SHACL? Why not JSON Schema?
In alignment with its Goals, IFC-LD must be remain serialization-agnostic. JSON Schema is applicable only to JSON, which itself is a data serialization format.
SHACL is also a more expressive schema language than JSON Schema. It is not possible to encode the existing IFC schemas in JSON Schema alone.
4.2. P21 to IFC-LD Instance Mappings
| P21 | IFC-LD |
|---|---|
Exchange File |
RDF Named Graph |
Header Section |
RDF property-value pairs linked to exchange’s named graph URI |
Data Section |
subject URIs of the named graph |
| P21 Header Property | IFC-LD |
|---|---|
file_description.description |
|
file_name.name |
|
file_name.time_stamp |
|
file_name.author |
|
file_name.organization |
|
file_schema |
| P21 Data Type | IFC-LD |
|---|---|
Entity |
URI |
Reference |
URI |
Boolean |
|
Logical |
|
Integer |
|
Real |
|
String |
|
Enumeration |
|
Binary |
|
Array |
|
Set |
RDF triples sharing same subject, predicate |
Null |
excluded from serialization; present in schema |
Derived |
excluded from serialization; present in schema |
4.4. IFC-LD Instance Examples
Here’s an example P21 IFC file and its equivalent IFC-LD named graph,serialized in both Turtle and JSON-LD:
ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('ViewDefinition [CoordinationView_V2.0]'),'2;1');
FILE_NAME('0001','2020-11-30T17:44:46',(''),(''),'The EXPRESS Data Manager Version 5.02.0100.07 : 28 Aug 2013','21.0.0.383 - Exporter 21.0.0.383 - IU alternativa 21.0.0.383','');
FILE_SCHEMA(('IFC4x2'));
ENDSEC;
DATA;
#1= IFCORGANIZATION($,'Autodesk Revit 2021 (ESP)',$,$,$);
#5= IFCAPPLICATION(#1,'2021','Autodesk Revit 2021 (ESP)','Revit');
#6= IFCCARTESIANPOINT((0.,0.,0.));
#9= IFCCARTESIANPOINT((0.,0.));
#11= IFCDIRECTION((1.,0.,0.));
#13= IFCDIRECTION((-1.,0.,0.));
#15= IFCDIRECTION((0.,1.,0.));
#17= IFCDIRECTION((0.,-1.,0.));
#19= IFCDIRECTION((0.,0.,1.));
#21= IFCDIRECTION((0.,0.,-1.));
#23= IFCDIRECTION((1.,0.));
#25= IFCDIRECTION((-1.,0.));
#27= IFCDIRECTION((0.,1.));
#29= IFCDIRECTION((0.,-1.));
#31= IFCAXIS2PLACEMENT3D(#6,$,$);
#32= IFCLOCALPLACEMENT(#147,#31);
#35= IFCPERSON($,'','CYPE',$,$,$,$,$);
#37= IFCORGANIZATION($,'','',$,$);
#38= IFCPERSONANDORGANIZATION(#35,#37,$);
#41= IFCOWNERHISTORY(#38,#5,$,.NOCHANGE.,$,$,$,1606175882);
#42= IFCSIUNIT(*,.LENGTHUNIT.,$,.METRE.);
#43= IFCSIUNIT(*,.AREAUNIT.,$,.SQUARE_METRE.);
#44= IFCSIUNIT(*,.VOLUMEUNIT.,$,.CUBIC_METRE.);
#45= IFCSIUNIT(*,.PLANEANGLEUNIT.,$,.RADIAN.);
#46= IFCDIMENSIONALEXPONENTS(0,0,0,0,0,0,0);
#47= IFCMEASUREWITHUNIT(IFCRATIOMEASURE(0.0174532925199433),#45);
#48= IFCCONVERSIONBASEDUNIT(#46,.PLANEANGLEUNIT.,'DEGREE',#47);
#49= IFCSIUNIT(*,.MASSUNIT.,.KILO.,.GRAM.);
#50= IFCDERIVEDUNITELEMENT(#49,1);
#51= IFCDERIVEDUNITELEMENT(#42,-3);
#52= IFCDERIVEDUNIT((#50,#51),.MASSDENSITYUNIT.,$);
#54= IFCDERIVEDUNITELEMENT(#42,4);
#55= IFCDERIVEDUNIT((#54),.MOMENTOFINERTIAUNIT.,$);
#57= IFCSIUNIT(*,.TIMEUNIT.,$,.SECOND.);
ENDSEC;
END-ISO-10303-21;@prefix ifc: <http://ifc-ld.org/schemas/ifc4x2#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
<http://base.com/guid> prov:generatedAtTime "2020-11-30T17:44:46"^^xsd:dateTime .
<http://base.com/guid#11> a ifc:ifcdirection ;
ifc:directionratios ( [ rdf:value 1.0 ] [ rdf:value 0.0 ] [ rdf:value 0.0 ] ) .
<http://base.com/guid#13> a ifc:ifcdirection ;
ifc:directionratios ( [ rdf:value -1.0 ] [ rdf:value 0.0 ] [ rdf:value 0.0 ] ) .
<http://base.com/guid#15> a ifc:ifcdirection ;
ifc:directionratios ( [ rdf:value 0.0 ] [ rdf:value 1.0 ] [ rdf:value 0.0 ] ) .
<http://base.com/guid#17> a ifc:ifcdirection ;
ifc:directionratios ( [ rdf:value 0.0 ] [ rdf:value -1.0 ] [ rdf:value 0.0 ] ) .
<http://base.com/guid#19> a ifc:ifcdirection ;
ifc:directionratios ( [ rdf:value 0.0 ] [ rdf:value 0.0 ] [ rdf:value 1.0 ] ) .
<http://base.com/guid#21> a ifc:ifcdirection ;
ifc:directionratios ( [ rdf:value 0.0 ] [ rdf:value 0.0 ] [ rdf:value -1.0 ] ) .
<http://base.com/guid#23> a ifc:ifcdirection ;
ifc:directionratios ( [ rdf:value 1.0 ] [ rdf:value 0.0 ] ) .
<http://base.com/guid#25> a ifc:ifcdirection ;
ifc:directionratios ( [ rdf:value -1.0 ] [ rdf:value 0.0 ] ) .
<http://base.com/guid#27> a ifc:ifcdirection ;
ifc:directionratios ( [ rdf:value 0.0 ] [ rdf:value 1.0 ] ) .
<http://base.com/guid#29> a ifc:ifcdirection ;
ifc:directionratios ( [ rdf:value 0.0 ] [ rdf:value -1.0 ] ) .
<http://base.com/guid#32> a ifc:ifclocalplacement ;
ifc:placementrelto <http://base.com/guid#147> ;
ifc:relativeplacement <http://base.com/guid#31> .
<http://base.com/guid#41> a ifc:ifcownerhistory ;
ifc:changeaction [ rdf:value "nochange"^^xsd:string ] ;
ifc:creationdate [ rdf:value 1606175882 ] ;
ifc:owningapplication <http://base.com/guid#5> ;
ifc:owninguser <http://base.com/guid#38> .
<http://base.com/guid#43> a ifc:ifcsiunit ;
ifc:name [ rdf:value "square_metre"^^xsd:string ] ;
ifc:unittype [ rdf:value "areaunit"^^xsd:string ] .
<http://base.com/guid#44> a ifc:ifcsiunit ;
ifc:name [ rdf:value "cubic_metre"^^xsd:string ] ;
ifc:unittype [ rdf:value "volumeunit"^^xsd:string ] .
<http://base.com/guid#48> a ifc:ifcconversionbasedunit ;
ifc:conversionfactor <http://base.com/guid#47> ;
ifc:dimensions <http://base.com/guid#46> ;
ifc:name [ rdf:value "degree"^^xsd:string ] ;
ifc:unittype [ rdf:value "planeangleunit"^^xsd:string ] .
<http://base.com/guid#52> a ifc:ifcderivedunit ;
ifc:elements <http://base.com/guid#50>,
<http://base.com/guid#51> ;
ifc:unittype [ rdf:value "massdensityunit"^^xsd:string ] .
<http://base.com/guid#55> a ifc:ifcderivedunit ;
ifc:elements <http://base.com/guid#54> ;
ifc:unittype [ rdf:value "momentofinertiaunit"^^xsd:string ] .
<http://base.com/guid#57> a ifc:ifcsiunit ;
ifc:name [ rdf:value "second"^^xsd:string ] ;
ifc:unittype [ rdf:value "timeunit"^^xsd:string ] .
<http://base.com/guid#9> a ifc:ifccartesianpoint ;
ifc:coordinates ( [ rdf:value 0.0 ] [ rdf:value 0.0 ] ) .
<http://base.com/guid#1> a ifc:ifcorganization ;
ifc:name [ rdf:value "autodesk revit 2021 (esp)"^^xsd:string ] .
<http://base.com/guid#31> a ifc:ifcaxis2placement3d ;
ifc:location <http://base.com/guid#6> .
<http://base.com/guid#35> a ifc:ifcperson ;
ifc:familyname [ rdf:value ""^^xsd:string ] ;
ifc:givenname [ rdf:value "cype"^^xsd:string ] .
<http://base.com/guid#37> a ifc:ifcorganization ;
ifc:description [ rdf:value ""^^xsd:string ] ;
ifc:name [ rdf:value ""^^xsd:string ] .
<http://base.com/guid#38> a ifc:ifcpersonandorganization ;
ifc:theorganization <http://base.com/guid#37> ;
ifc:theperson <http://base.com/guid#35> .
<http://base.com/guid#45> a ifc:ifcsiunit ;
ifc:name [ rdf:value "radian"^^xsd:string ] ;
ifc:unittype [ rdf:value "planeangleunit"^^xsd:string ] .
<http://base.com/guid#46> a ifc:ifcdimensionalexponents ;
ifc:amountofsubstanceexponent [ rdf:value 0 ] ;
ifc:electriccurrentexponent [ rdf:value 0 ] ;
ifc:lengthexponent [ rdf:value 0 ] ;
ifc:luminousintensityexponent [ rdf:value 0 ] ;
ifc:massexponent [ rdf:value 0 ] ;
ifc:thermodynamictemperatureexponent [ rdf:value 0 ] ;
ifc:timeexponent [ rdf:value 0 ] .
<http://base.com/guid#47> a ifc:ifcmeasurewithunit ;
ifc:unitcomponent <http://base.com/guid#45> ;
ifc:valuecomponent [ rdf:value 0.0174532925199433 ] .
<http://base.com/guid#49> a ifc:ifcsiunit ;
ifc:name [ rdf:value "gram"^^xsd:string ] ;
ifc:prefix [ rdf:value "kilo"^^xsd:string ] ;
ifc:unittype [ rdf:value "massunit"^^xsd:string ] .
<http://base.com/guid#5> a ifc:ifcapplication ;
ifc:applicationdeveloper <http://base.com/guid#1> ;
ifc:applicationfullname [ rdf:value "autodesk revit 2021 (esp)"^^xsd:string ] ;
ifc:applicationidentifier [ rdf:value "revit"^^xsd:string ] ;
ifc:version [ rdf:value "2021"^^xsd:string ] .
<http://base.com/guid#50> a ifc:ifcderivedunitelement ;
ifc:exponent [ rdf:value 1 ] ;
ifc:unit <http://base.com/guid#49> .
<http://base.com/guid#51> a ifc:ifcderivedunitelement ;
ifc:exponent [ rdf:value -3 ] ;
ifc:unit <http://base.com/guid#42> .
<http://base.com/guid#54> a ifc:ifcderivedunitelement ;
ifc:exponent [ rdf:value 4 ] ;
ifc:unit <http://base.com/guid#42> .
<http://base.com/guid#6> a ifc:ifccartesianpoint ;
ifc:coordinates ( [ rdf:value 0.0 ] [ rdf:value 0.0 ] [ rdf:value 0.0 ] ) .
<http://base.com/guid#42> a ifc:ifcsiunit ;
ifc:name [ rdf:value "metre"^^xsd:string ] ;
ifc:unittype [ rdf:value "lengthunit"^^xsd:string ] .{
"@context": {
"@base": "http://base.com/guid#",
"@vocab": "http://ifc-ld.org/schemas/ifc4x2#",
"ifc": "http://ifc-ld.org/schemas/ifc4x2#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"data": "@graph",
"a": "@type",
"id": "@id"
},
"id": "#",
"prov:generatedAtTime": "2020-11-30T17:44:46",
"data": [
{
"id": "#31",
"a": "ifcaxis2placement3d",
"location": {
"id": "#6"
}
},
{
"id": "#47",
"a": "ifcmeasurewithunit",
"unitcomponent": {
"id": "#45"
},
"valuecomponent": {
"rdf:value": {
"@value": "0.0174532925199433"
}
}
},
{
"id": "#46",
"a": "ifcdimensionalexponents",
"amountofsubstanceexponent": {
"rdf:value": 0
},
"electriccurrentexponent": {
"rdf:value": 0
},
"lengthexponent": {
"rdf:value": 0
},
"luminousintensityexponent": {
"rdf:value": 0
},
"massexponent": {
"rdf:value": 0
},
"thermodynamictemperatureexponent": {
"rdf:value": 0
},
"timeexponent": {
"rdf:value": 0
}
},
{
"id": "#35",
"a": "ifcperson",
"familyname": {
"rdf:value": ""
},
"givenname": {
"rdf:value": "cype"
}
},
{
"id": "#49",
"a": "ifcsiunit",
"name": {
"rdf:value": "gram"
},
"prefix": {
"rdf:value": "kilo"
},
"unittype": {
"rdf:value": "massunit"
}
},
{
"id": "#19",
"a": "ifcdirection",
"directionratios": {
"@list": [
{
"rdf:value": {
"@value": 0.0
}
},
{
"rdf:value": {
"@value": 0.0
}
},
{
"rdf:value": {
"@value": 1.0
}
}
]
}
},
{
"id": "#42",
"a": "ifcsiunit",
"name": {
"rdf:value": "metre"
},
"unittype": {
"rdf:value": "lengthunit"
}
},
{
"id": "#37",
"a": "ifcorganization",
"description": {
"rdf:value": ""
},
"name": {
"rdf:value": ""
}
},
{
"id": "#48",
"a": "ifcconversionbasedunit",
"conversionfactor": {
"id": "#47"
},
"dimensions": {
"id": "#46"
},
"name": {
"rdf:value": "degree"
},
"unittype": {
"rdf:value": "planeangleunit"
}
},
{
"id": "#43",
"a": "ifcsiunit",
"name": {
"rdf:value": "square_metre"
},
"unittype": {
"rdf:value": "areaunit"
}
},
{
"id": "#17",
"a": "ifcdirection",
"directionratios": {
"@list": [
{
"rdf:value": {
"@value": 0.0
}
},
{
"rdf:value": {
"@value": -1.0
}
},
{
"rdf:value": {
"@value": 0.0
}
}
]
}
},
{
"id": "#25",
"a": "ifcdirection",
"directionratios": {
"@list": [
{
"rdf:value": {
"@value": -1.0
}
},
{
"rdf:value": {
"@value": 0.0
}
}
]
}
},
{
"id": "#1",
"a": "ifcorganization",
"name": {
"rdf:value": "autodesk revit 2021 (esp)"
}
},
{
"id": "#15",
"a": "ifcdirection",
"directionratios": {
"@list": [
{
"rdf:value": {
"@value": 0.0
}
},
{
"rdf:value": {
"@value": 1.0
}
},
{
"rdf:value": {
"@value": 0.0
}
}
]
}
},
{
"id": "#54",
"a": "ifcderivedunitelement",
"exponent": {
"rdf:value": 4
},
"unit": {
"id": "#42"
}
},
{
"id": "#5",
"a": "ifcapplication",
"applicationdeveloper": {
"id": "#1"
},
"applicationfullname": {
"rdf:value": "autodesk revit 2021 (esp)"
},
"applicationidentifier": {
"rdf:value": "revit"
},
"version": {
"rdf:value": "2021"
}
},
{
"id": "#9",
"a": "ifccartesianpoint",
"coordinates": {
"@list": [
{
"rdf:value": {
"@value": 0.0
}
},
{
"rdf:value": {
"@value": 0.0
}
}
]
}
},
{
"id": "#41",
"a": "ifcownerhistory",
"changeaction": {
"rdf:value": "nochange"
},
"creationdate": {
"rdf:value": 1606175882
},
"owningapplication": {
"id": "#5"
},
"owninguser": {
"id": "#38"
}
},
{
"id": "#51",
"a": "ifcderivedunitelement",
"exponent": {
"rdf:value": -3
},
"unit": {
"id": "#42"
}
},
{
"id": "#50",
"a": "ifcderivedunitelement",
"exponent": {
"rdf:value": 1
},
"unit": {
"id": "#49"
}
},
{
"id": "#57",
"a": "ifcsiunit",
"name": {
"rdf:value": "second"
},
"unittype": {
"rdf:value": "timeunit"
}
},
{
"id": "#32",
"a": "ifclocalplacement",
"placementrelto": {
"id": "#147"
},
"relativeplacement": {
"id": "#31"
}
},
{
"id": "#55",
"a": "ifcderivedunit",
"elements": {
"id": "#54"
},
"unittype": {
"rdf:value": "momentofinertiaunit"
}
},
{
"id": "#13",
"a": "ifcdirection",
"directionratios": {
"@list": [
{
"rdf:value": {
"@value": -1.0
}
},
{
"rdf:value": {
"@value": 0.0
}
},
{
"rdf:value": {
"@value": 0.0
}
}
]
}
},
{
"id": "#52",
"a": "ifcderivedunit",
"elements": [
{
"id": "#50"
},
{
"id": "#51"
}
],
"unittype": {
"rdf:value": "massdensityunit"
}
},
{
"id": "#44",
"a": "ifcsiunit",
"name": {
"rdf:value": "volumeunit"
},
"unittype": {
"rdf:value": "cubic_metre"
}
},
{
"id": "#29",
"a": "ifcdirection",
"directionratios": {
"@list": [
{
"rdf:value": {
"@value": 0.0
}
},
{
"rdf:value": {
"@value": -1.0
}
}
]
}
},
{
"id": "#38",
"a": "ifcpersonandorganization",
"theorganization": {
"id": "#37"
},
"theperson": {
"id": "#35"
}
},
{
"id": "#11",
"a": "ifcdirection",
"directionratios": {
"@list": [
{
"rdf:value": {
"@value": 1.0
}
},
{
"rdf:value": {
"@value": 0.0
}
},
{
"rdf:value": {
"@value": 0.0
}
}
]
}
},
{
"id": "#45",
"a": "ifcsiunit",
"name": {
"rdf:value": "planeangleunit"
},
"unittype": {
"rdf:value": "radian"
}
},
{
"id": "#21",
"a": "ifcdirection",
"directionratios": {
"@list": [
{
"rdf:value": {
"@value": 0.0
}
},
{
"rdf:value": {
"@value": 0.0
}
},
{
"rdf:value": {
"@value": -1.0
}
}
]
}
},
{
"id": "#23",
"a": "ifcdirection",
"directionratios": {
"@list": [
{
"rdf:value": {
"@value": 1.0
}
},
{
"rdf:value": {
"@value": 0.0
}
}
]
}
},
{
"id": "#27",
"a": "ifcdirection",
"directionratios": {
"@list": [
{
"rdf:value": {
"@value": 0.0
}
},
{
"rdf:value": {
"@value": 1.0
}
}
]
}
},
{
"id": "#6",
"a": "ifccartesianpoint",
"coordinates": {
"@list": [
{
"rdf:value": {
"@value": 0.0
}
},
{
"rdf:value": {
"@value": 0.0
}
},
{
"rdf:value": {
"@value": 0.0
}
}
]
}
}
]
}4.5. Acknowledgements
Created by Devon Sparks (devonsparks.com) with input from members of the BuildingSmart community. IFC-LD is not currently an officially sponsored BuildingSmart International project.
Thanks to the stepcode team for collaboration on supporting pull requests for the STEP P21 parser and answering questions about the design of the STEP EXPRESS parser.