Skip to content

Commit

Permalink
Merge pull request #369 from buildingSMART/#339-identifier-docs
Browse files Browse the repository at this point in the history 
Update ids-metadata.md
  • Loading branch information
@CBenghi
CBenghi authored Nov 7, 2024
2 parents eff6e57 + 4149cc8 commit 0571d78
Showing 1 changed file with 13 additions and 11 deletions.
24 changes: 13 additions & 11 deletions Documentation/UserManual/ids-metadata.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,21 +8,23 @@ Each `.ids` file has basic metadata that are common to all **Specifications** li

| Name | Description | Examples |
| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Title | The document title of the IDS, used to refer to the IDS as a whole | "Minimum delivery requirements" or "Costing Requirements" |
| Copyright | The copyright owner of the IDS | "Example Company Pty Ltd" or "Government Department X" |
| Version | The version of the IDS, to keep track of changes that have been made. Semantic versioning is recommended where versioning follows the naming scheme of X.Y, where Y represents a minor change, such as changes in metadata, description, or spelling errors, and X represents a major change, where models that used to pass or fail in a previous version may yield a different result. | "1.0" or "2.1" |
| Author | The author of the IDS, provided as an email contact address | "<[email protected]>" |
| Date | The date the IDS was published | "2022-01-01" |
| Description | One or more sentences that further elaborate on a description who the IDS might be for, why it is created, what projects it might apply to, and so on. | "Minimum requirements for all OpenBIM projects to ensure basic coordination and data scheduling can be done by all stakeholders. Expected to be run prior to model sharing and is a requirement for all project milestones." or "Specifies required properties that have a large impact on the accuracy of cost estimation and quantities that are necessary for automated model-based quantity take-off. To be read in conjunction with the cost planning geometry guideline and reinforcing modeling practices guide". |
| Purpose | Why the information is needed. | "quantity take off", "accessibility analysis", "clash detection", "coordination", "cost estimation". |
| Milestone | Delivery milestone when the information is needed. | "Schematic Design", "Construction", "Commissioning", "RIBA Stage 3", "As-built", "Planning", "350", "400". |
| title | The document title of the IDS, used to refer to the IDS as a whole | "Minimum delivery requirements" or "Costing Requirements" |
| copyright | The copyright owner of the IDS | "Example Company Pty Ltd" or "Government Department X" |
| version | The version of the IDS, to keep track of changes that have been made. Semantic versioning is recommended where versioning follows the naming scheme of X.Y, where Y represents a minor change, such as changes in metadata, description, or spelling errors, and X represents a major change, where models that used to pass or fail in a previous version may yield a different result. | "1.0" or "2.1" |
| author | The author of the IDS, provided as an email contact address | "<[email protected]>" |
| date | The date the IDS was published | "2022-01-01" |
| description | One or more sentences that further elaborate on a description who the IDS might be for, why it is created, what projects it might apply to, and so on. | "Minimum requirements for all OpenBIM projects to ensure basic coordination and data scheduling can be done by all stakeholders. Expected to be run prior to model sharing and is a requirement for all project milestones." or "Specifies required properties that have a large impact on the accuracy of cost estimation and quantities that are necessary for automated model-based quantity take-off. To be read in conjunction with the cost planning geometry guideline and reinforcing modeling practices guide". |
| purpose | Why the information is needed. | "quantity take off", "accessibility analysis", "clash detection", "coordination", "cost estimation". |
| milestone | Delivery milestone when the information is needed. | "Schematic Design", "Construction", "Commissioning", "RIBA Stage 3", "As-built", "Planning", "350", "400". |

## Specification metadata

Each **Specification** has metadata to help describe the goals and instructions of how to achieve it.

| Name | Description | Examples |
| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Name | A short name of what information is being specified | "Wall type naming conventions" or "Concrete quantity take-off dimensions" |
| Description | Describe why the requirement is important to the project. The person reading the description should understand why the information provides value, which workflows it helps to achieve, and what project benefits will be sacrificed if the requirements are not met. | "Basic properties that have significant impacts on costing, detailing, and building renovations must be included to minimise construction risk." |
| Instructions | Provide instructions on who is responsible to provide the information and details on how it is achieved, such as guidelines on how a naming convention works, how to choose an appropriate value, or what to do in edge-cases | "Architects and code consultants are responsible for providing this information. Where there are multiple values, the dominant value shall be indicated." |
| name | A short name of what information is being specified | "Wall type naming conventions" or "Concrete quantity take-off dimensions" |
| description | Describe why the requirement is important to the project. The person reading the description should understand why the information provides value, which workflows it helps to achieve, and what project benefits will be sacrificed if the requirements are not met. | "Basic properties that have significant impacts on costing, detailing, and building renovations must be included to minimise construction risk." |
| instructions | Provide instructions on who is responsible to provide the information and details on how it is achieved, such as guidelines on how a naming convention works, how to choose an appropriate value, or what to do in edge-cases | "Architects and code consultants are responsible for providing this information. Where there are multiple values, the dominant value shall be indicated." |
|ifcVersion | What IFC version(s) are expected. Options: "IFC2X3", "IFC4", "IFC4X3_ADD2" | "IFC4X3_ADD2" |
|identifier | For clear and unambiguous identification, allowing for easier tracking, referencing, and reporting. It should be unique within an IDS file. | "SP01", "Fire-001", "5b1b0426-a21d-4ee9-9b53-e9b7827690a7" |

0 comments on commit 0571d78

Please sign in to comment.