Contributors:
construct: class, object property, or data property
entity (object): item that is perceivable or conceivable
Note 1 to entry: The terms ‘entity’ and ‘object’ are catch-all terms analogous to ‘something’. In terminology circles
[ISO/IEC 21838-1:2021(E)]
particular: individual entity
Note 1 to entry: In contrast to classes or types, particulars are not exemplified or instantiated by further entities
[ISO/IEC 21838-1:2021(E)]
instance: particular that instantiates some universal
[ISO/IEC 21838-1:2021(E)]
primitive: expression for which no non-circular definition can be provided
Note 1 to entry: construct lacking necessary or sufficient conditions
[ISO 21838-2:2021 (E)]
Note 2 to entry: definition refers to a first-order logic definition or OWL definition
universal: item that is perceivable or conceivable that has indefinitely many instances
[ISO 21838-2:2021 (E)]
axiom: statement that is asserted as true but which is not derivable from other statements
Note 1 to entry: Axioms may be formulated as natural language sentences or as formulae in a formal language. In the OWL community, ‘Axiom’ is used to refer to statements that say what is true in the domain that are ‘basic’ in the sense that they are not inferred from other statements.
[ISO/IEC 21838-1:2021(E)]
Note 2 to entry: A statement may be a formula of first-order logic or a sentence of natural language or of the semi-formal counterpart
The IOF AnnotationVocabulary (AV) OWL file (AnnotationVocabulary) is the normative source for IOF annotation properties. It includes a superset of the annotation properties discussed in this document along with the metadata about them. This document’s purpose is to provide the requirements and instructions for authors of IOF ontologies. The AV should be imported into IOF ontologies under development to make these annotation properties available; however, since the IOF Core imports IOF AV, using AV requires no explicit owl:imports statement.
The rules in this document changed some of the annotations needed by IOF ontologies as compared to those used in Core beta and before, deprecating at least one annotation property and adding a few additional. A revision of the AV consistent with this document was uploaded to the iofoundry/CoreDev GitHub repo (only) 2 Aug 2022, but older versions of the AV will not provide complete support.
All approved ontologies MUST adhere to the following annotation requirements for all constructs.
The following rules MUST be followed when using this document; these are taken from IETF RFC 2119 (simplified):
MUST: This word means that the definition is an absolute requirement of the specification.
MUST NOT: This phrase means that the definition is an absolute prohibition of the specification.
SHOULD: This word means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications MUST be understood and carefully weighed before choosing a different course.
SHOULD NOT: This phrase means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
MAY: This word means that an item is truly optional. One user may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.
The following annotations MUST be provided for all IOF ontologies:
MUST provide non-versioned ontology iri (See: IRI Structure and Format 2022-02 )
MUST provide version iri (owl:VersionIRI)(See: IRI Structure and Format 2022-02 )
The following annotations MUST be given in all ontologies:
MUST provide label
MUST provide title
MUST provide abstract
MUST provide copyright
MUST provide license
The following annotations MUST be given for all constructs:
MUST provide label
MUST provide natural language definition
If the isPrimitive annotation is set to true:
MUST provide primitive rationale
MAY provide first-order language axioms and semi-formal natural language axioms
example MUST be provided
If the isPrimitive annotation is set to false or not specified:
MUST provide first-order logic definition
MUST provide semi-formal natural language definition
The following annotations SHOULD be given for all constructs and annotation properties:
SHOULD provide example
In cases where a text annotation is needed, an American English language version of that annotation is required and MUST use the American English language tag ( xml:lang="en-US"). Spelling in American English annotations MUST conform to an American dictionary, such as Merriam-Webster. Additional annotations covering the same material but expressed in a different natural language are allowed as long as they incorporate the proper language tag. Text annotations that include a language tag have a default datatype of rdf:langString. By definition from the RDFS 1.1 specification, one MUST NOT include an explicit datatype when adding an annotation.
The following is an example of the Ontology annotations from Core. Annotations in the “Active Ontology” tab in Protégé.
<owl:Ontology rdf:about="https://purl.industrialontologies.org/ontology/core/Core/"> <rdfs:label xml:lang="en">Core Ontology</rdfs:label> <dcterms:abstract>The IOF Core Ontology contains terms and concepts found to be common across multiple domains of industry and represents an OWL implementation of them. The ontology itself utilizes the Basic Formal Ontology or BFO as a philosophical foundation but also imports terms from various domain-independent or "mid-level" ontologies. The purpose of the ontology is to serve or is intended to serve as a core for IOF's domain-specific ontologies, with a goal being to ensure consistency and interoperability across the suite of ontologies the IOF publishes.</dcterms:abstract> <dcterms:contributor xml:lang="en">Elisa Kendall, Thematix Partners LLC</dcterms:contributor> <dcterms:contributor xml:lang="en">Will Sobel, W. V. Sobel LLC</dcterms:contributor> <dcterms:creator xml:lang="en">Chris Will, National Center for Ontological Research (NCOR)</dcterms:creator> <dcterms:creator xml:lang="en">IOF Core Working Group</dcterms:creator> <dcterms:license rdf:datatype="&xsd;anyURI">http://opensource.org/licenses/MIT</dcterms:license> <dcterms:publisher xml:lang="en">Industrial Ontology Foundry</dcterms:publisher> <dcterms:references rdf:resource="http://purl.org/dc/terms/"/> <dcterms:references rdf:resource="http://www.w3.org/2004/02/skos/core#"/> <dcterms:title>Industrial Ontology Foundry (IOF) Core Ontology</dcterms:title> |
label - rdfs:label
Each construct MUST have at least one natural language label, as follows:
Exactly one American English language label MUST be provided and language tagged
Labels MUST be unique across all IOF ontologies and SHOULD be unique across all imported non-IOF ontologies in a given natural language
Labels for other natural languages MAY be provided, but if so they must be language tagged
Data property MUST be a verb phrase starting with is for boolean (true/false) or has for any other data type.
Example: is transferable
Data property SHOULD end with value
Example: has numeric value
label text MUST be given in lowercase with spaces between words
Exception: proper names MUST use initial upper-case
Exception: Words like DNA that are capitalized in the Oxford English Dictionary (Home: OED ) MUST remain in uppercase
Acronyms MUST NOT be used for label values
Exception: Words like RADAR and DNA with dictionary definitions MAY be used and will be considered by the architecture TG
Note - The IOF annotation vocabulary does not include an annotation property for preferred label. Instead, an annotation directly asserted as an rdfs:label in IOF OWL content is treated as the preferred label.
Alternative (non-preferred) labels MAY also be provided for a construct using the following annotations
synonym annotation MUST be used for alternative labels that are not abbreviations
abbreviation annotation MUST be used for shortened alternative labels other than acronyms
When the acronym does not appear in the dictionary, acronym annotation MUST be used
natural language definition – iof-av:naturalLanguageDefinition
Definition: plain text for industry practitioner understanding
The natural language definition MUST be given for all constructs
Note: this definition MUST be present for both primitive constructs and non-primitive
The natural language definition MUST occur exactly once
The definition MUST adhere to ISO 704 rules and requirements for terminology
For non-primitive constructs, the natural language definition MUST NOT be circular
For primitive constructs, the natural language definition SHOULD NOT be circular
The definition MUST be substitutable in a sentence where the term appears
We MAY reconsider this as a requirement if there is no way to express it as a formal substitutable definition. There MUST be a rationale, expressed as an explanatory note, for why this is the case and the rationale MUST be agreed to by the Architecture TG.
The definition MUST NOT begin with an article (The, A or An).
One SHOULD avoid jargon and domain-specific terminology
It MUST be understandable by a practitioner in the industrial domain
It MUST NOT use specialized ontological terminology
Examples: perdurant, endurant, continuant, etc.
Ontological construct label MUST be provided in parenthesis
Example: role held by (bearer of) a material entity when it is a proper part of another material entity or is planned to be a proper part of another material entity
It MUST NOT use special formatting for properties or classes referenced in the definition
MUST NOT use upper camel case capitalization
MUST NOT use apostrophes to contain terms as a parenthetical
Examples: must not be as follows: ‘part-of’, ‘Information Content Entity', InformationContentEntity
It MUST NOT contain acronyms or abbreviations
Acronyms MAY be accepted if they appear in the dictionary and are widely used in conversation. Acronym use MUST be approved by the Architecture TG.
If the definition is taken from another source, dcterms:source or one of its sub-properties MUST cite the original reference. See dcterms:source in the Source Annotations section below.
Examples:
shipment preparation process: planned process in which some material entities are prepared to be transported together to a receiver’s location
postal address: designation of a location (site) to which mail is delivered
elucidation -- iof-av:elucidation
elucidation MUST NOT be used and is deprecated.
is primitive – iof-av:isPrimitive
Definition: boolean flag indicating that necessary and sufficient conditions are not provided
is primitive MUST be present if the term does not have necessary and sufficient conditions and the value of the annotation MUST be set to true (w3c boolean)
Otherwise, if necessary and sufficient conditions are present, then the annotation MAY be provided and the value MUST be set to false
is primitive MUST default to set to false
If possible, terms SHOULD have necessary and sufficient conditions
Note: the term may not always remain primitive if necessary and sufficient conditions can be defined in a later version
Example:
person: true
shipment preparation process: true
primitive rationale – iof-av:primitiveRationale
Definition: reason why the necessary and sufficient conditions could not be provided
When is primitive is set to true , the primitive rationale MUST be provided
The primitive rationale MUST explain why necessary and sufficient conditions are not possible
The rationale SHOULD indicate what is missing if additional work is required to define necessary and sufficient conditions
Example:
person: insufficient constructs to create necessary and sufficient conditions
shipment preparation process: shipment preparation process often includes at least one picking, internal movement, packaging, marking, weighing, or loading process, but since those processes are not added to the ontology yet, it is not possible to generate necessary and sufficient conditions at this time for this entity
The following rules MUST be followed when using variables in a first-order logic axiom (formalization) or definition and semi-formal natural language axiom or definition
MUST NOT nest variables in single quotes
Examples: 'instance i' ‘, 'continuant c’
MUST use lower case variable for particular (individual or instance) of a universal
Variable SHOULD use the first letter of a construct’s label when possible
Variable MUST only be one letter
MUST append numeric suffixes (x1, x2, etc.) OR one or more primes (x', x'', etc.) for multiple instances of the same construct
MUST reserve the use of t, t', etc., for temporal regions; expressions such as 'for all times' SHOULD be interpreted as meaning ‘for all temporal regions’
MUST only use r, r', s, s', etc., for spatial and spatiotemporal regions
MUST only the use of R, R', etc. for relations
MUST NOT use the character a or A
first-order logic definition – iof-av:firstOrderLogicDefinition
Definition: formal definition of construct using predicate logic semantics
The syntax MUST adhere to part one of the following article: https://www.cs.ox.ac.uk/people/james.worrell/lecture9-2015.pdf
The first-order logic definition MUST occur exactly once if the term is not primitive (is primitive is false )
If is primitive is set to false, the definition SHOULD provide individually necessary and sufficient conditions
The definition MUST adhere to the following semantics:
References to classes and properties MUST use the label. The label MUST be transformed where the spaces are removed and classes labels MUST use UpperCamelCase and properties MUST use lowerCamelCase.
Examples:
material entity becomes MaterialEntity
has part at some time becomes hasPartAtSomeTime
See also: IRI Structure and Format for the format of constructs
All terms MUST use a prefix if they are external the current ontology
All prefixes referenced MUST be declared in the ontology prefixes even if not used in the axioms of the ontology
https://en.wikipedia.org/wiki/First-order_logic
ISO/IEC PRF 21838‐1:2020
The definition MUST only use the following symbols:
Symbol | Meaning | UTF-8 Code |
|---|---|---|
∧ | Conjunction | U+2227 |
∨ | Disjunction | U+2228 |
¬ | Negation | U+00AC |
∃ | Existential Quantification | U+2203 |
∀ | Universal Quantification | U+27C7 |
→ | Implication/Conditional | U+2192 |
↔ | Equivalence/Bi-Implication | U+2194 |
( ) | Left/Right Parentheses | Left: U+0028, Right: U+0029 |
[ ] | Left/Right Square Brackets | Left: U+005B, Right: U+005D |
{ } | Left/Right Braces | Left: U+007B, Right: U+007D |
Examples:
product:
obo:Continuant(c) ∧ ¬(obo:SpecificallyDependentContinuant(c) ∨ Person(c) ∨ Organization(c)) ∧ ∃r (ProductRole(r) ∧ obo:hasRole(c, r))
semi-formal natural language definition – iof-av:semiFormalNaturalLanguageDefinition
Definition: transitional definition expressing first-order logic definition using semantics understandable by ontologically knowledgable domain practitioner without predicate logic semantics
The semi-formal natural language definition MUST be provided if the term is not primitive (is primitive is false )
The semi-formal natural language definition MUST only occur once
Variables SHOULD be removed if they do not need to be referenced later in the expression
Rules for writing necessary axioms, sufficient axioms, and necessary and sufficient axioms:
SHOULD use “every instance of {term} is defined as exactly an instance of {conditions}” for necessary and sufficient conditions
Example (Necessary and Sufficient Axiom): ‘agent’: every instance of ‘agent’ is defined as exactly an instance of ‘person’, ‘group of agents’, or ‘engineered system’ that ‘has role’ some ‘agent role’
The following syntax MUST be used:
A construct label MUST be used and its exact syntax preserved for constructs in this or an imported ontology
Quotes (') MUST surround all labels
The words “is a” MUST NOT be used without a qualification
“is a subclass of” MUST be used to indicate a subclass relationship
“is an instance of” MUST be used to indicate an instance of a universal
Variables SHOULD be used where needed in formulating the definition
The rules for natural language definitions MUST be applied otherwise
Examples:
‘product’: every instance of ‘product' is defined as exactly an instance of (‘continuant’ and not ‘person’ and not ‘organization’ and not ‘specifically dependent continuant’) that ‘bears' some ‘product role’
‘agent’: every instance of ‘agent’ is defined as exactly an instance of ‘person’, ‘group of agents’, or ‘engineered system’ that ‘has role’ some ‘agent role’
logic axiom - iof-av:logicAxiom
Definition: logical statements constraining the interpretation of the notion represented by the construct that does not provide necessary and sufficient conditions
Note: This annotation property is an abstraction of the more specialized logic axiom annotations used in IOF. However, this annotation property can also be used to group the logic axiom annotation values of different forms (such as FOL and natural language) that express the same meaning for a particular construct
A first-order logic axiom expression and a semi-formal natural language axiom expression SHOULD be added as property values for each logic axiom annotation using one of each of the corresponding logic axiom annotation sub-properties
Example:
iof-av:logicAxiom [ iof-av:firstOrderLogicAxiom "GenericallyDependentContinuant(x) ∧ ∃e(Entity(e) ∧ isAbout(x,e)) ->InformationContentEntity(x)" ; iof-av:semiFormalNaturalLanguageAxiom "x is a 'Generically Dependent Continuant' that 'is About' some 'Entity' e implies x is an 'Information Content Entity'" ; ] . |
first-order logic axiom - iof-av:firstOrderLogicAxiom
Definition: axiom of construct using predicate logic semantics
First-order logic axiom MAY be provided if the construct is primitive or non-primitive.
With the implication arrow → the left is sufficient and the right is necessary
A construct MAY have more than one first-order logic axiom annotation
A first-order logic axiom value MUST adhere to first-order logic definition syntax
If there is more than one axiom, the axiom MUST be associated with the semi-formal natural axiom
Examples:
GenericallyDependentContinuant(x) ∧ ∃e(Entity(e) ∧ isAbout(x,e)) →InformationContentEntity(x)
semi-formal natural language axiom - iof-av:semiFormalNaturalLanguageAxiom
Definition: transitional definition expressing first-order logic axiom using semantics understandable by ontologically knowledgable domain practitioner without predicate logic semantics
Semi-formal natural language axioms MAY be provided if the term is primitive (is primitive is true )
A construct MAY include more than one semi-formal natural language axiom annotation
The definition MUST adhere to semi-formal natural language definition syntax
If there is more than one axiom, the axiom MUST be associated with the first-order logic axiom
All variables refer to instances
Rules for writing a necessary or sufficient axiom:
SHOULD use if and then to indicate the implication/conditional pattern for necessary or sufficient axiom: if antecedent, then consequent
AgentRole(x) → Role(x) ∧ ∃m ∃n ((MaterialEntity(m) ∧ ¬FiatObjectPart(x)) ∧ (Person(n) ∨ GroupOfAgents(n) ∨ EngineeredSystem(n)) ∧ actsOnBehalfOfAtSomeTime(m, n) ∧ roleOf(x,m))
'agent role': if x is an instance of 'agent role', then x is an instance of 'role' that is the 'role of' some ('material entity' and not 'fiat object part') that 'acts on behalf of at some time' some other 'person', 'group of agents', or 'engineered system'
SHOULD use some type of for a universal pattern
InformationContentEntity(x) ∧ ∃c, ∃r ( continuant(c) ∧ RequirementSpecification(r) ∧ satisfies(x,r) ∧ prescribes(x,c)) ∧ ∀c'(prescribes(x,c') → Continuant(c')) → DesignSpecification(x)
if d is a ‘design specification’, then d is an ‘information content entity’ that ‘prescribes' some type of 'continuant'
SHOULD use whenever when representing a multi-place temporal expression
∀ p,q,t (hasContinuantPart(p, q, t) ∧ instanceOf(p, MaterialEntity, t) → instanceOf(q, site, t) ∨ instanceOf(q, ContinuantFiatBoundary, t) ∨ instanceOf(q, MaterialEntity, t)
whenever a ‘material entity’ ‘has part’ y then y must be a ‘site’ or a ‘material entity’ or a ‘continuant fiat boundary’
example – skos:example
Definition: supplies an example of the use of a concept [skos]
ex:organizationsOfScienceAndCulture skos:example: "academies of science, general museums, world fairs" [skos]
example MUST provide a correct use of the construct in a domain context
constructs SHOULD include example
see also – rdfs:seeAlso
Definition: rdfs:seeAlso is an instance of rdf:Property that is used to indicate a resource that might provide additional information about the subject resource [rdfs]
see also: https://www.w3.org/wiki/UsingSeeAlso
The reference MUST be a concise reference to the related documentation
The reference SHOULD be a URL if possible, otherwise a brief description of the external reference
A source is a related resource from which the described resource is derived. Since annotations can be applied to annotations, the appropriate source annotation property described below SHOULD be attached to the element where the influence of the source manifests. This element could be an entire construct or an annotation on a construct such as a natural language definition. A source annotation SHOULD be concise, but may be in the form of a URL, bibliographic citation, or other standard description.
direct source – iof-av:directSource
Definition: definitive source of the subject resource
adapted from – iof-av:adaptedFrom
Definition: source for the resource that was modified to create the subject resource
comment – rdfs:comment
comment MUST NOT be used. Use one of the following instead:
iof-av:explanatoryNote
iof-av:usageNote
skos:scopeNote
explanatory note – iof-av:explanatoryNote
Definition: supplemental information used to clarify or describe the construct
explanatory note MAY be used to supplement the natural language definition of the construct
Example: “Item is another term semantically close to Product. But it is more general because Item may not sellable. It is an overloaded term used by information systems to capture catalog information about real and sort of unreal (e.g., product family or option class which is a group of similar products) materials the enterprise concerns with.”
usage note – iof-av:usageNote
Definition: describes how to use the term in particular situations
usage note MAY be used to describe how the term is used in particular situations through an example instantiation.
Example: “This is how the Supplying Relation class may be used to convey who supplies what to who. SupplierRole(sr1) and BuyerRole(br1) and Product(p1) and SupplyingRelation(s1) and specificallyDependsOn(s1, sr1) and specificallyDependsOn(br1, s1) and specificallyDependsOn(p1,s1)”
scope note – skos:scopeNote
If required, scope note MUST be used to provide additional domain contextualization on the use of the term
From skos:
A note that helps to clarify the meaning and/or the use of a concept
Example:
General Rules
Synonyms and abbreviations MUST include language tag xml:lang.
synonym – iof-av:synonym
Definition: alternate label that may help users discover the construct
synonym MAY be used to indicate alternate term. If alternate term is context specific, it SHOULD be supplemented with the scope note annotation.
Example:
“process plan” is a synonym for the “plan specification” in the context/scope of discrete manufacturing, “recipe” is a synonym for the “plan specification” in the context/scope of batch and continuous manufacturing.
symbol – iof-av:symbol
Definition: terse designation (abbreviation) for the construct
One SHOULD use symbol when a commonly used abbreviation exists, such as chemical symbols or units of measure
Examples:
m (meter)
C (carbon)
abbreviation – iof-av:abbreviation
Definition: alternate short label for the element
One SHOULD use abbreviation when there is an alternate short label
One MUST use symbol if the abbreviation is a chemical or unit of measure.
acronym – iof-av:acronym
Definition: specialized abbreviation
One SHOULD use acronym when there is a commonly accepted acronym
Examples:
PLM (Product Lifecycle Maintenance)
CAD (Computer Aided Design)
The following annotations apply to an entire IOF ontology and not to individual constructs of the ontology
copyright – iof-av:copyright
Definition: originator’s and authorized entity’s exclusive legal right to print, distribute, and publish material
Inspired by OED.
Ontologies MUST have a copyright annotation
license – dcterms:license
Defintion: legal document giving official permission to do something with the resource [dcterms]
Ontologies MUST have a license annotation
abstract - dcterms:abstract
Definition: A summary of the resource [dcterms]
Ontologies MUST have an abstract annotation
This document identifies each annotation property using an abbreviated form of its full IRI with the structure <prefix>:<local name>, where the prefix represents the namespace IRI, and the local name is the identifier for the resource within the namespace. The full IRI is the concatenation of the local name to the namespace IRI; for example, skos:scopeNote represents http://www.w3.org/2004/02/skos/core#scopeNote. An ontology author may never use this expanded form directly. However, for completeness, a table below is provided that enumerates all the prefixes used in the document along with the namespaces that they represent.
Prefix | Namespace |
|---|---|
dcterms | |
iof-av | https://purl.industrialontologies.org/ontology/core/meta/AnnotationVocabulary/ |
owl | |
rdfs | |
skos |
ISO 704
ISO 10241
ISO/IEC 21383-2:2020 (EN) Information Technology – Top-Level Ontology – Basic Formal Ontology
Link w/o paywall?
6.2.3.2 Upper case characters, mathematical symbols, typographical signs and syntactic signs (e.g. punctuation marks, hyphens, parentheses, square brackets and other connectors or delimiters) as well as their character styles (i.e. fonts and bold, italic, bold italic, or other style conventions) shall be used in a term only if they constitute part of the normal written form of the term as conventionally used in running text. Syntactic signs shall not be used to show alternative terms. For complex terms (e.g. compounds and multiword terms), the natural word order shall be retained.
Examples and discussion
for necessary and sufficient conditions
Example (Necessary Axiom): if d is an instance of ‘design specification’, then d is an instance of ‘information content entity’ that ‘prescribes' only instances of 'continuant' (if any)
Alt 2: if d is an instance of ‘design specification’, then d is an instance of ‘information content entity’ that ‘prescribes' only instances of 'continuant'
Alt 3: if d is a ‘design specification’, then d is an ‘information content entity’ that ‘prescribes' some 'continuant'
** BS Alt 4: if d is a ‘design specification’, then d is an ‘information content entity’ that ‘prescribes' some type of 'continuant'
SK Alt 5: if d is a ‘design specification’, then d is an instance of ‘information content entity’ that ‘prescribes’ some type of ‘entity’, and if so, the entity must be a ‘continuant’
Alt 6: if d is a ‘design specification’, then d is an ‘information content entity’ that ‘prescribes' only types of 'continuant'
Example (Sufficient Axiom): if x is an ‘information content entity’ that ‘prescribes' some (‘process characteristic’ or ‘capability’ or 'continuant') that is the 'output of' some 'process', then x is an 'objective specification’
Domain and Range:
domain(R,C) iff for all x,y (xRy --> Cx)
range(R,C') iff for all x,y (xRy --> C'y)
We need an example for: (maybe one from BFO)
Foo ⊑ ∀ foobar.Bar
Without proofreading: ∀ x (Foo(x) → (∃ y(foobar(x,y) → Bar(y))))
JL thinks the FOL would be this: ∀x,y(Foo(x) → (∀y(foobar(x,y) → Bar(y)))
JL first proposed text: “If x is an instance of ‘foo’, then if x has a ‘foobar’ relationship with y, then y is an instance of Bar“
Examples:
if x is a 'generically dependent continuant' that 'is about' some 'entity' then x is an 'information content entity'
‘algorithm’: if x is an instance of ‘plan specification’ that ‘prescribes' some ‘computing process’, then x is an 'algorithm’
x is an Algorithm if and only if x is a PlanSpecification and there is some y such that y is a ComputingProcess and y prescribes x
Which is equivalent of the conjunction of the following two assertions
if x is a PlanSpecification and there is some y such that y is a ComputingProcess and y prescribes x, then x is an Algorithm
if x is an Algorithm, then x is a PlanSpecification and there is some y such that y is a ComputingProcess and y prescribes x
'agent role': if x is an instance of 'agent role', then x is an instance of 'role' that is the 'role of' some ('material entity' and not 'fiat object part') that 'acts on behalf of at some time' some other 'person', 'group of agents', or 'engineered system'
Milos:
∀x,y(Foo(x) ∧ foobar(x,y) → Bar(y)))
∀x (Foo(x) → (∀y(foobar(x,y) → Bar(y)))
∀x (Foo(x) → (∀y(¬(foobar(x,y)) ∨Bar(y)))
Milos BFO Examples:
From BFO:
If a ‘has continuant part’ b then if a is an instance of ‘material entity’ then b is an instance of ‘site’ or ‘continuant fiat boundary’ or
'material entity' [mic-1]
Corresponding owl axiom:
'has continuant part at some time' only (site or 'material entity' or 'continuant fiat boundary')
Proposed IOF axiom:
if x ‘has continuant part at some time’ y then y must be an instance of ‘site’ or ‘material entity’ or ‘continuant fiat boundary’
From BFO: b has continuant part c at some time =Def for some time t (b and c are continuants & b is a part of c at t)
Alternatively:
There exists no y for which x ‘has continuant part at some time’ y holds that is not an instance of ‘site’ or ‘material entity’ or ‘continuant fiat boundary’
FOL: ∀ p,q,t (hasContinuantPart(p, q, t) ∧ instanceOf(p, MaterialEntity, t) → instanceOf(q, site, t) ∨ instanceOf(q, ContinuantFiatBoundary, t) ∨ instanceOf(q, MaterialEntity, t)
To be translated to CL eventually.
With the temporal relation: (solution for multi-place temporal relation). Use whenever for t. x ‘has continuant part at some time’ y → whenever x ‘has part’ y
'at some time' → whenever
A. whenever a ‘material entity’ ‘has continuant part’ y then y must be a ‘site’ or a ‘material entity’ or a ‘continuant fiat boundary’
** B. whenever a ‘material entity’ ‘has part’ y then y must be a ‘site’ or a ‘material entity’ or a ‘continuant fiat boundary’
Rationale: we need to write the FOL for the future, but not introduce new predicates
C. whenever a ‘material entity’ ‘has part’ y then y must be a ‘site’ or a ‘material entity’ or a ‘continuant fiat boundary’ (and every part of a ‘material entity’ is a ‘continuant’)
D. whenever a ‘material entity’ ‘has part’ y then y must be a ‘site’ or a ‘material entity’ or a ‘continuant fiat boundary’
every part of a ‘material entity’ is a ‘continuant’
Rules for managing changes to the definitions
Barry’s comments: