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

On 04-06-14 22:35, Simon Spero wrote:
> On Wed, Jun 4, 2014 at 10:25 AM, Andreas Kuckartz <a.kuckartz@ping.de
> <mailto: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.

Actually, this is not so weird. This approach has the advantage that the 
value space is easily extendible with new "gender values" (gender is 
such a fluent thing in our society; extensibility could be useful in the 
future).

For a discussion of the pros and cons of this approach see Alan Rector's 
note of this subject, published in as part of the work of the Semantic 
Web Best Practices Working Group:

   http://www.w3.org/TR/swbp-specified-values/

Guus


>
>     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 . ]
>
>

Received on Wednesday, 4 June 2014 22:15:46 UTC