Use of relationship in partOf

[CBenghi]

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

• any IfcRelAggregates class pointing to the IfcMember we are checking, via RelatedObjects, has a RelatingObject of type IFCDOOR.

I see two options:

1) there's gonna be a documented approach to what attributes (in this case relatedObjects and RelatingObject) we should traverse

2) 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

[aothms]

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.

[CBenghi]

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.

[CBenghi]

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

[berlotti]

yes, option one was the idea. Good point to make a list per IFC version!

[Moult]

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".

[CBenghi]

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

[Moult]

@CBenghi just checked the PR, it still has a huge list of relations, I don't see much point in duplicating the IFC docs, and the four relationships are already mentioned here as well as clearly elaborated in testcases for devs.

[CBenghi]

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.