Community Specifications Committee logo

Handbook: Table of Contents
► Governing Board committees: Membership & Finance ◘ Nominations & Bylaws
► Technical Board committees: Usage ◘ Standards & Liaisons ◘ Community Specifications ◘ Infrastructure Advisory Committee (IAC)
► Advisory Board committees: Conferences & Meetings ◘ Education & Outreach
► Management: Executive ◘ Directorate


Contents


NKOS AP Homepage

NKOS AP Property/Class Tables

  1. General Notes
    1. [SS] The draft domain model (graphic) denotes/implies relationships of the <rdfs:domain> - <rdfs:range> or <schema:domainIncludes> - <schema:rangeIncludes> sort and yet some of the tables have such notations in their tables and others do not. We should walk through the properties and look at:
      1. whether total lack of either <rdfs:domain> or the ontologically looser <schema:domainIncludes> is intended; and
      2. whether those property tables with "has range" really mean the formal inferencing of <rdfs:range>; or, whether the AP creators' intention is the ontologically "looser" notions of <schema:rangeIncludes> -- denoting classes from which the property may be expected to draw values but for which no formal inferencing of class is desired or intended.
  2. Class tables - file: 4Classes-Word2014-11-06.docx (Dropbox)
    1. Notes
      • @@@
  3. Property tables - file: 5Properties-Word2014-11-06 (Dropbox)
    1. Notes
      • [SS] There needs to be a table for every property used in the AP. You should not collapse two properties into one table and then try to explain through usage note when to use which property. This will lead to confusion and misuse. For example, you should have a single table for the notion of creator as resource (thing - <dct:creator> (i.e., dcterms namespace)) and a separate table for the notion of creator as literal (string) - <dc:creator> (i.e., dc namespace). Each table then can have it's own usage note that clearly drives home when to use which one and the thing/string distinction.