Closed CBenghi closed 2 years ago
Given the fact that this is an enumeration in the XSD (the only one remaining?) I think that option one makes the most sense, because as you say it's the more lightweight option. Option 2 is a bit more mvdXML-y where you have to traverse (inverse...?) attributes at runtime which poses some additional requirements on the implementation.
So in summary, I vote for 1, with a light sadness in my heart we can't have option 2.
I think option 1 would work for version one with the table and then it remains expandable in future releases if it's found useful. I will produce a document early next week to document the attributes for each of the relations.
I've started drafting the table from IFC4; I'll complete and review other schema version when I find the time.
Relation type | Relation instance attribute | Relation element attribute |
---|---|---|
IfcRelAssigns (abstract) | RelatedObjects | |
IfcRelAssignsToActor | RelatedObjects | RelatingActor |
IfcRelAssignsToControl | RelatedObjects | RelatingControl |
IfcRelAssignsToGroup | RelatedObjects | RelatingGroup |
IfcRelAssignsToGroupByFactor | RelatedObjects | RelatingGroup |
IfcRelAssignsToProcess | RelatedObjects | RelatingProcess |
IfcRelAssignsToProduct | RelatedObjects | RelatingProduct |
IfcRelAssignsToResource | RelatedObjects | RelatingResource |
IfcRelAssociates (abstract) | RelatedObjects | |
IfcRelAssociatesApproval | RelatedObjects | IfcRelAssociatesApproval |
IfcRelAssociatesClassification | RelatedObjects | RelatingClassification |
IfcRelAssociatesConstraint | RelatedObjects | RelatingConstraint |
IfcRelAssociatesDocument | RelatedObjects | RelatingDocument |
IfcRelAssociatesLibrary | RelatedObjects | RelatingLibrary |
IfcRelAssociatesMaterial | RelatedObjects | RelatingMaterial |
IfcRelConnects (abstract) | n/a | |
IfcRelConnectsElements | RelatedElement | RelatingElement |
IfcRelConnectsPathElements | RelatedElement | RelatingElement |
IfcRelConnectsWithRealizingElements | RelatedElement | RelatingElement |
IfcRelConnectsPorts | RelatedPort | RelatingPort |
IfcRelConnectsPortToElement | RelatedElement | RelatingPort |
IfcRelConnectsStructuralActivity | RelatedStructuralActivity | RelatingElement |
IfcRelConnectsStructuralMember | RelatedStructuralConnection | RelatingStructuralMember |
IfcRelConnectsWithEccentricity | RelatedStructuralConnection | RelatingStructuralMember |
IfcRelContainedInSpatialStructure | RelatedElements | RelatingStructure |
IfcRelCoversBldgElements | RelatedCoverings | RelatingBuildingElement |
IfcRelCoversSpaces | RelatedCoverings | RelatingSpace |
IfcRelFillsElement | RelatedBuildingElement | RelatingOpeningElement |
IfcRelFlowControlElements | todo | todo |
IfcRelInterferesElements | todo | todo |
IfcRelReferencedInSpatialStructure | todo | todo |
IfcRelSequence | todo | todo |
IfcRelServicesBuildings | todo | todo |
IfcRelSpaceBoundary | todo | todo |
IfcRelSpaceBoundary1stLevel | todo | todo |
IfcRelSpaceBoundary2ndLevel | todo | todo |
IfcRelDeclares | todo | todo |
IfcRelDecomposes (abstract) | todo | todo |
IfcRelAggregates | todo | todo |
IfcRelNests | todo | todo |
IfcRelProjectsElement | todo | todo |
IfcRelVoidsElement | todo | todo |
IfcRelDefines (abstract) | todo | todo |
IfcRelDefinesByObject | todo | todo |
IfcRelDefinesByProperties | todo | todo |
IfcRelDefinesByTemplate | todo | todo |
IfcRelDefinesByType | todo | todo |
yes, option one was the idea. Good point to make a list per IFC version!
I don't think partOf should/can cover every single relationship, there is quite a large scope and the intention of user requirements behind being "part of" a physical thing vs "assigned to" a virtual thing (actors?) probably shouldn't be lumped together. I'd prefer to be more cautious and stick to only 4 relationships for IDS v1 and gradually finetune it as IDS gets battletested.
Also everybody keeps on forgetting about IfcResourceLevelRelationship. Maybe I'm the only lonely implementer :)
IDS only specifies 4 relationships: https://github.com/buildingSMART/IDS/blob/master/Development/0.9/ids_09.xsd#L239-L242 - each of which should check the the RelatingFoo as per the English use of the phrase "partOf".
I've created a PR for documentation and discussion purposes with different Schema version. Rather than adding it to the PartOf facet it felt more appropriate to add it to the the developers document, let me know what you think.
See #82
I thought it might be helpful for future evolution of the facet, in the evaluation of more relations to include. I'm not sure how we came to the selection of the 4 relations, but I see how it might seem to be too much. I'll close the PR.
Hello,
In the following example in the codebase:
https://github.com/buildingSMART/IDS/blob/8b25b29efae09c5e1c76f4183471e21615cfe420/Development/0.9/IDS_wooden-windows.xml#L10-L24
I assume that we want to check that
IfcRelAggregates
class pointing to theIfcMember
we are checking, viaRelatedObjects
, has aRelatingObject
of typeIFCDOOR
.I see two options:
1) there's gonna be a documented approach to what attributes (in this case
relatedObjects
andRelatingObject
) we should traverse2) we include these in the specification file (something like
<ids:entity relation="IfcRelAggregates" via="RelatedObjects" to="RelatingObject" >
).I am happy with both scenario, the first is more lightweight, the second more extensible and futureproof.
I'd be happy to draft the documentation for case 1 if that's the chosen option.
Best, Claudio