Re: gender: Why does vCard Ontology define class hierarchy instead of skos:Concept resources ?

On Wed, Jun 4, 2014 at 10:25 AM, Andreas Kuckartz <a.kuckartz@ping.de>
wrote:

> The vCard Ontology uses a class hierarchy to formulate gender
> values (vcard:Female, vcard:Male, vcard:None, vcard:Other and vcard:Unknown
> as subclasses of vcard:Gender).
>
> That is unusual and not really usable.
>


> Why is no skos:ConceptScheme with skos:Concept resources used for
> that purpose?
>

 It's not unprecedented  to model genders as a classes;  the extension of a
class being everything that is of that gender. Within the domain of vcard,
this corresponds to humans (hence no vegetable or numeric genders), and
would seem to be restricted to gender of identification.

This approach can have several advantages;  for example,  one could define
Cis and Trans as subclasses of Gender, with CisMale ≣ (Cis and Male) being
automatically classified appropriately.  People would be instances of a
Gender... except... that's not what is being done here:

There is an objectProperty "hasGender", with no specified domain or range.

There is text on the HTML page (§2.3)  that states that hasGender "[s]hould
only apply to Individual. See Gender Codes in Section 2.11.".
 The ontology itself, merely states that "To specify the sex or gender
identity of the object. URIs are recommended to enable interoperable sex
and gender codes to be used."

Representing the missing domain statement is easy;  appropriately
restricting the range is somewhat more difficult.

All of the sub-classes of Gender are classes, not Genders.  In a system
like CycL, you could tersely state that an argument of a property had to be
a subclass of specified class, but OWL does not provide such a feature. In
OWL 2 Full one could build a restriction expressing this constraint, but
you would probably not want to.

Under OWL 2 DL, it is perfectly ok to use the IRI of a class as a named
individual;  however, this "punning" does not stop you from using any other
IRI as the value of hasGender (e.g. :fred vcard:hasGender vcard:Fax. is
perfectly legal).

If one wanted to make the range of  vcard:hasGender be vcard:Gender, then
the values need to instances of the class.  An easy way to do this is to
make the subclasses of vcard:Gender be instances of vcard:Gender.

If vcard:Gender is intended is not intended to be a hierarchy, then the
subclass relationships and membership of owl:Class can be removed from
various Genders.

If the class of genders is supposed  to be an enumeration, then
vcard:Gender can be declared as a disjoint union; a semi open list could be
supported by an additional property, with a hasGender value of Other being
inferred.

[Also,    vcard:hasURL a owl:ObjectProperty ???
This should be an owl:DataProperty with range xsd:anyURI . ]