Upper Ontologies

Based on the article by Mascardi, Cordi and Rosso [MaCo07a] a table of formal upper ontologies was created. It contains information about the developers, the first release and last update, as well as metric information about the number of classes, object properties and axioms. Of these, the most relevant to this paper are discussed in this section and in section Top Level Ontologies.

"A well-known and quite comprehensive ontology available today is Cyc, a proprietary system under development since 1986, consisting of a foundation ontology and several domain-specific ontologies (called microtheories). A subset of that ontology has been released for free under the name OpenCyc, and a more or less unabridged version is made available for free non-commercial use under the name ResearchCyc. "

"The Suggested Upper Merged Ontology (SUMO) is another comprehensive ontology project. It includes an upper ontology, created by the IEEE working group P1600.1 (originally by Ian Niles and Adam Pease). It is extended with many domain ontologies and a complete set of links to WordNet. It is open source. "

"Schema.org is a collaborative, community activity with a mission to create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond. Over 10 million sites use Schema.org to markup their web pages and email messages. A shared vocabulary makes it easier for webmasters and developers to decide on a schema and get the maximum benefit for their efforts. "

• Organization of Schemas: "The schemas are a set of 'types', each associated with a set of properties. The types are arranged in a hierarchy. The vocabulary currently consists of 797 Types, 1453 Properties 14 Datatypes, 86 Enumerations and 462 Enumeration members."
• The page https://schema.org/docs/releases.html lists schema.org releases, most recent first.
• "The data model used is very generic and derived from RDF Schema (which in turn was derived from CycL, see History section for details ...)."
• "The type hierarchy presented on this site is not intended to be a 'global ontology' of the world."

Names of data and object properties start with a lower case letter. Schema.org makes no difference in naming between data properties like height and object properties like actors. In the Ontology4 adaption we use our naming conventions instead.  So types and enumerations are prefixed with the character ^, data properties with . and object properties with  <>.

Other naming conventions of Schema.org as listed in the styleguide are:

• "Do not give the same name to a type and a property." In our approach we avoid this by using different prefixes. There are lots of examples listed below where Schema.org does not follow this guideline.
• Property names must use lowerCamelCase for format (first word lowercase, subsequent words capitalized, all one string).
• "Prepositions should come after the type or property name. E.g. reservationFor."
• "Abbreviations: When creating new types, spell out abbreviations, unless the result is painfully verbose. "
• "Spelling: US spellings must be used. E.g. color and not colour."

Furthermore attributes like "award" and "awards" are defined as ^Text though it is obvious, that in the plural form the relation between ^CreativeWork and ^Award is meant: (^CreativeWork, ◊Award, ^Award ). On the opposite they use singular and plural form for relations to objects like in (^CreativeWork, ◊encoding, ^MediaObject) and (^CreativeWork, ◊encodings, ^MediaObject).

Obviously Schema.org does also assume that names of classes and properties are case sensitive. This will e.g. not be supported by data base systems like SQL.

One approach to solve the problem with the naming of object properties would be to add prefixes and suffixes like in hasChild or isChildOf. This would be in line with the Schema.org naming conventions. But then on the other side has should not be used with data properties like in hasOccupation and hasCredential. One example where it is used in this way is hasMap in Place.

Other questions:

• Why is location a property and not a type? What differentiates it from the type Place?
• Why is event a property and not a type? Why is the plural events neede?
• Why containedInPlace and not isPartOf_Place where isPartOf_Place would be a subObjectProperty of isPartOf?

The are numerous examples in Schema.org where both singular and the plural form of an object property is provided. We think that it would be enough to more correct to use only the singular form. E.g. the children of a person indicates that the range of the object property is a set of children which is not the case.

Other examples are:

• actor, actors
• attendee, attendees
• colleague, colleagues
• employee, employees
• founder, founders
• member, members
• sibling, siblings

Another weakness of Schema.org is that they use verbs for naming object properties, e.g.

• offers. Here as inverse-property itemOffered is specified. We think this is not a good choice since offers could e.g. also be interpreted in the sense of offering a service or capability.

The following object properties do not provide an inverse-property. We provide an alternative noun for each of them for which easily the inverse-property can be specified:

• nowsLanguage ◊isKnowerOf = ◊hasKnower-1
• owns: ◊isOwnerOf = ◊hasOwner-1
• seeks: ◊isSearcherOf = ◊hasSearcher-1
• teaches ◊isTeacherOf = ◊hasTeacher-1

When using nouns instead of verbs in the naming of object properties the name of the inverse object property can be automatically derived according to the Object Property Naming Guidelines.

Schema.org uses open world philosophy (OWA): the omission of a claim should not be taken to imply negation: if a property isn't mentioned, this doesn't mean that it is false. Rather, it means that we don't know whether it's true or false. E.g. restaurant, petsAllowed is a boolean property (T/F) of LodgingBusiness, but if petsAllowed is not set, then it is unknown whether pets are allowed.