Best practices for modeling location entities in Brick v1.4.0?

[Sarah MacDougall]

Hi,

With the introduction of REC space classes in Brick v1.4.0, there are also new REC relationships.  I'd appreciate your help in clarifying the recommended modeling for space classes in Brick v1.4.0.

1. How do you recommend users model the physical location of equipment?

            a. Do you recommend using the rec:isLocationOf/rec:LocatedIn relationship for users to model the physical location of equipment?  The brick:isLocationOf relationship is not deprecated in Brick v1.4.0, but rec:isLocationOf is associated with rec:Space and this seems to be the preferred Brick relationship because they are taking all location related concepts from Real Estate Core. Is this true?

    b. If you recommend using the rec relationships instead of brick equivalents, then is it an oversite that these classes are not asymetric properties in the Brick v 1.4.0 schema .ttl?   For example, rec:isLocationOf is equivalent to brick:isLocationOf, but is not a owl:AsymmetricProperty in Brick v1.4.0. rec:locatedIn is equivalent to brick:hasLocation, but is not a owl:AsymmetricProperty in Brick v1.4.0

    Should rec:isLocationOf & rec:locatedIn be owl:AsymmetricProperties?                                                        

2. How do you recommend users model location entities part of other location entities? 

For example, in Brick v1.3.0, you would model a space as part of a floor using the triple: Floor ‘brick:hasPart’ Space.

Do you recommend modeling these types of relationships with the rec:hasPart/rec:isPartOf instead of brick:hasPart/brick:isPartOf?

If so, the rec classes are subclasses of the Brick classes and are not equivalent properties like rec:isLocationOf & rec:locatedIn. These are also not owl:AsymmetricProperties.  Is this an oversight?  Or is this intentional?

Thanks,

Sarah