Are duplicate property names a problem?

[jakebeal]

When we've been working with SBOL extension ontologies, we've had problems with using the same property name in disjoint classes. This leads me to a concern that we may be creating a problem with reusing property names in different contexts.

Consider, for example, @goksel 's declaration of the SBOL 2 type property:

<owl:ObjectProperty rdf:about="http://sbols.org/v2#type">
        <rdfs:domain>
            <owl:Class>
                <owl:unionOf rdf:parseType="Collection">
                    <rdf:Description rdf:about="http://sbols.org/v2#ComponentDefinition"/>
                    <rdf:Description rdf:about="http://sbols.org/v2#Interaction"/>
                </owl:unionOf>
            </owl:Class>
        </rdfs:domain>
        <tawny:name xml:lang="en">type</tawny:name>
        <rdfs:comment xml:lang="en">Specifies the category of biochemical or physical entity. For example DNA, protein, or small molecule that a ComponentDefinition object abstracts for the purpose of engineering design. For DNA or RNA entities, additional types fields are used to describe nucleic acid topology (circular / linear) and strandedness (double- or single-stranded).</rdfs:comment>
        <rdfs:label xml:lang="en">type</rdfs:label>
    </owl:ObjectProperty>

The domain is a union over two classes. In this case, the range is always a URI, so we can get away with using a union, but if the range types were also disjoint then this would not correctly describe the constraints, since it would allow for the combinations that shouldn't be there.

We've run into this problem in building extension classes and resolved it by making the names distinct, but that feels inelegant. My question is this: is there a correct way to declare a property with two disjoint uses?

• If so, I'd like to know about it and start using it in our extensions.
• If not, we should write this design constraint explicitly into the preamble material of the specification.

[jakebeal]

Consensus: this is not a problem.

[PrashantVaidyanathan]

@jakebeal - I'm closing this issue based on your most recent comment.