Request for Clarification

IndependentParty vs. AutonomousAgent

What if any relationship is there between IndependentParty and AutonomousAgent? It makes sense that every IndependentParty is an AutonomousAgent, but that subclass relationship is not there.

Recommended Changes

Naming Conventions for MediatingThings, ThingsInRole & RelativeThings & connecting properties

There is a property called isProducedBy which is supposed to only be used with RelativeThings. For the record, the definition is currently:  “The target or range of this property should be read as always being some kind of 'relative thing', that is a thing defined in some context. Generally this will be a 'party in role'. This property is not intended to be used to relate a thing to some independent thing which it is provided by, only to something in the role of being that which provides it.”  

...

This example points out something else.  The definition tells us to only use the isProducedBy property when the property is acting in the producer role.  In this case they are producing the credit report in their role as a credit reporting agency, not more norrowly as a producer.  Experian might produce something else but not in their role as a CreditReportingAgency, this would require yet another role instance for Experian.  Yet another reason to avoid mediating things whenver possible.

ReFactoring Suggestions

• Suggest move the hasName data property to the relations ontology. Many things that are not agents have names .  Then there may be no need for relations ontology to be importing agents ontology. It seems a bit backwards. 
• Suggest move identifies(isIdentifiedBy) properties to the relations ontology. Many things that are not agents have identifiers.  Then the agents ontology can import the relations ontology, like most other ontologies do.
• Suggest change name of rel:hasUniqueIdentifier to rel:hasUniqueString to avoid confusion with the class, Identifier.

Properties with too narrow domain and/or range

rel:refersTo property has too narrow domain (Reference)

The property refersTo in the relations ontology has an overly narrow domain: Reference.  Every Reference refersTo something, but a person or a document or a report can refer to something, and it is not true that individual persons, documents or reporets are examples of " a concept that refers to (or stands in for) another concept".

...

Proposed solution: just remove the domain for refersTo, and all other properties that have indeterminately broad potential usage.

doc:hasExpirationDate has too narrow domain (Document)

It is currently not possible for an agreement to have an expiration date, because only Documents are allowed to have expiration dates

Proposed solution: just remove the domain for doc:hasExpirationDate

doc:hasDateOfIssuance has too narrow domain (Document)

It is currently not possible for anything to be issued unless it is a Document, thus the current ontology requires every financial instrument (which is currently a WrittenContract) to also be a Document.  Is that desirable?  

Proposed solution: just remove the domain for doc:hasDate

fd:hasCount has too narrow domain (RegularSchedule)

Data property: hasCount only applies to a RegularSchedule, but many things can be counted, e.g. the number of entries in a report, or number of members of a collection.

Proposed solution: just remove the domain for fd:hasCount

rel:uses has too narrow domain (AutonomousAgent)

The domain for uses is AutonomousAgent. Unlike the other examples, this one immediately seems reasonable and defensible from an intuitive and ontological perspective. Yet from a practical perspective, the domain is still too narrow. Outside of finance per se you can say an Argument uses a line of reasoning or that ontology uses a design pattern.  This is convenient and useful (as it were), even though strictly, the agent creating the argument or the ontology is doing the direct using.  In finance, there is a CreditScoring Occurrence whereby an algorithm is used to compute the credit score.  Strictly  the agent doing the work was using the model. But there is no reason to introduce an Agent here, that information is never tracked. I want to use the rel:uses property to link the credit scoring occurrence directly to the model.  In English this is fine, it makes sense to say algorithm X was used by this Occurrence of coming up with a credit score.   Lots of things might use something else, and it is hard to say what they all might be, so probably best to remove the domain. An alternate strategy is to try soemthing like Agent OR Occurrence (and anything else we can thyink of) and then if we run inference one day and find a problem we can keep extending the domain as needed. Not clear what the pros/cons are. 

Proposed solution: just remove the domain for rel:uses

rel:isMemberOf has too narrow domain 

isMemberOf should be general, now there is need to create a isGenericMemberOf.
UPDATE: this may have been fixed now. 

Recommended Additions

datatype property for version indicator

hasVersion string valued.

...