HasPropertyOf

There is a trend to prefix property names with "has" and suffix them with "of". In RDFS, we have rdfs:subClassOf and rdfs:subPropertyOf and so on. The wine example from the OWL guide uses hasMaker to relate a wine to its maker. Using the RoleNoun pattern, that would just be maker.

Some ontologies, e.g. a FRBR ontology go so far as to coin pairs embodiment and embodimentOf. It's one thing to notice, post-hoc, that two previuosly created properties are inverses, but it seems costly to purposefully coin two properties for each relationship. While there are some things that are awkward to say in RDF/XML syntax without explicit inverse properties, the cost of writing these awkward expressions seems lower than dealing with these aliases: which one should be used in queries? Both? While owl:inverseOf standardizes the relevant inferences, they are still not without cost.

NotationThree has syntactic support for keeping the has/of stuff out of the property URI:

<#bob> has :brother <#joe> .

<#joe> is :brother of <#bob> .

See also:

• Backward and Forward links in RDF just as important by timbl on Wed, 2006-01-25
• frbr:embodiment is enough without frbr:embodimentOf, no? by connolly on Wed, 2005-12-28
• Avoiding URI aliases in Web Architecture.

---

What of SKOS? How much redundancy:

skos:semanticRelation

 +-- skos:broader

 +-- skos:narrower

 +-- skos:related

Querying can be a pain (i.e. having to infer the inverse first) but the human naming is convenient - shouldn't it be the computer doing the work..?