复用不同命名规范（驼峰式与下划线式）本体的规范咨询——HVAC故障检测与诊断本体开发中的命名冲突问题

Great question—this is a super common pain point when mixing and matching domain ontologies for specialized work like HVAC fault detection. Let’s break this down clearly:

Is modifying reused class names to fit your camelCase convention "compliant" ontology reuse? #

Short answer: It depends on how you do it, but directly editing the original DigitalBuilding/Brick ontology files to rename classes (e.g., changing State to hvacState) is generally not considered best practice for strict, interoperable reuse. However, creating local adaptations that align your naming convention while preserving the original ontology’s semantic meaning is fully compliant—even encouraged.

Ontology reuse is all about inheriting or aligning with the semantics (class hierarchies, property constraints, domain/range rules) of the source, not just preserving syntax like naming conventions. If you create a new camelCase class in your own namespace, link it to the original DigitalBuilding State via owl:equivalentClass or rdfs:subClassOf, and keep all the original semantic rules intact, that’s a valid adaptation. The problem comes when you rename the original class without documenting the mapping back to the source—this breaks interoperability with tools or other users expecting the standard DigitalBuilding/Brick class names.

Industry guidelines for handling naming convention conflicts #

There are well-established practices to navigate this without breaking reuse:

• Use semantic mapping instead of direct modification
  Don’t edit the source ontologies. Instead, define your own camelCase classes in a dedicated namespace (e.g., myhvac:) and link them to the source classes. For example:

  # Your camelCase class in your namespace
  myhvac:HvacState rdfs:subClassOf db:State ;
                   rdfs:label "HVAC State"@en .
  
  # Keep the original DigitalBuilding class intact
  db:State rdfs:label "State"@en .
  

  This way, you get your naming consistency while maintaining full semantic alignment with the original ontology.

• Leverage labels for human-readable consistency
  If you want to use camelCase in your tooling without creating new classes, assign camelCase labels to the original source classes using rdfs:label or skos:prefLabel. Tools can then pick up the appropriate label for display, while the underlying ontology structure stays true to the source:

  db:State rdfs:label "hvacState"@en ; # Your camelCase display label
           rdfs:label "State"@en .     # Original source label
  

• Isolate namespaces
  Keep the original Brick and DigitalBuilding ontologies in their default namespaces (e.g., brick: for BrickSchema, db: for DigitalBuilding) and your custom classes in your own namespace. This avoids polluting the source ontologies and makes all mappings explicit at a glance.

• Follow W3C Ontology Best Practices
  The W3C’s ontology engineering guidelines emphasize modularity and interoperability. They recommend adapting ontologies through extension (building new classes that inherit from source classes) rather than modifying the source itself. This ensures your work stays compatible with other systems that rely on the standard Brick or DigitalBuilding ontologies.

• Document every adaptation
  No matter which approach you take, thoroughly document the mappings between your camelCase classes and the original source classes. Note which source class you’re adapting, why you adjusted the name, and how you’ve preserved the original semantics. This is critical for future maintenance and for anyone else who might integrate your HVAC fault detection ontology.

Quick recommendation for your specific case #

Instead of renaming DigitalBuilding’s State directly, create a myhvac:HvacState (or myhvac:State) class in your namespace, link it to db:State via subclass/equivalence, and stick to camelCase for your own classes. For Brick’s Location class, you can either use it directly with a camelCase label or create a myhvac:Location subclass if you need to add custom HVAC-specific constraints.

内容的提问来源于stack exchange，提问作者arash