Skip to content

Commit

Permalink
More on ontologies + logical spreadsheets
Browse files Browse the repository at this point in the history
  • Loading branch information
inariksit committed Jun 26, 2020
1 parent be57cea commit bdbdfe0
Show file tree
Hide file tree
Showing 5 changed files with 61 additions and 35 deletions.
12 changes: 0 additions & 12 deletions introduction_to_logical_spreadsheets.md

This file was deleted.

31 changes: 31 additions & 0 deletions logical_spreadsheets.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
---
date: "2020-06-16"
tags:
- todo
---

# Logical spreadsheets

_Quotes from Kassoff and Valente (2007) [An introduction to logical spreadsheets](http://logic.stanford.edu/people/mkassoff/papers/introtologicalspreadsheets.pdf)_

Logical spreadsheets are an extension to traditional spreadsheets.

Traditional spreadsheets can do mathematical computations, along with simple Boolean functions and conditionals. Logical spreadsheets have more use cases, examples by Kassoff and Valente: _"performing symbolic what-if analyses, and transforming data from one representation to another. [] data entry and validation, enterprise management, and constraint-solving."_

Kassoff and Valente list some benefits of logical spreadsheets:

> * reduce errors in spreadsheet design (by checking errors or limiting the ways in which users make mistakes);
> * make it easier to perform some common spreadsheet tasks (e.g. specifiy certain constraints or queries);
> * allow users to specify what they intend more declaratively;
> * provide a different/complementary abstraction;
> * make it easier to perform certain tasks (e.g. query across tables);
> * make it easier to express/use complex (business) rules, and make them more readable and main-
tainable;
> * use logic to debug and reason about spreadsheet contents;
> * add more powerful, expressive modeling capabilities through logic expressions;
> * additional new reasoning capabilities (e.g. constraint reasoning);
> * help users build models in spreadsheets.
TODO: read more of the paper, list modern applications

Sounds a bit similar to <dmn_constraint_tables_extension>?
32 changes: 23 additions & 9 deletions ontology.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,14 +9,19 @@ tags:

Collection of concepts and their relationships, in a machine-readable format.

<sumo> is a big, well-known general ontology. (Most of the examples here are from SUMO, but the general concepts of taxonomy, relationships etc. aren't limited to SUMO.)
## Domain ontology vs. upper ontology

### Taxonomy

The basic building block of an ontology is a hierarchy of concepts. Higher nodes represent general concepts, lower nodes more specific. Example:

Domain ontologies describe details of a particular domain. Examples of domain ontologies are a biomedical ontology (or even more specific, only about neurology), or an ontology about airports.

In contrast, an _upper ontology_ (synonyms: _top-level ontology_, _foundation ontology_) "describes very general concepts that are the same across all domains. The aim is to have a large number on ontologies accessible under this upper ontology.” (Mascardi et al. (2007) [A Comparison of Upper Ontologies](http://personales.upv.es/prosso/resources/MascardiEtAl_WOA07.pdf))

In the following picture, the domain ontologies of Neurology and Airports are connected to an upper ontology, which starts from very generic terms. Note that this is not the actual hierarchy of any real ontology, just a hypothetical example.

Entity
/ | \
… … … … … …
Biology … Geography
/ | | \ … … / | | \
… … … … … … … … … … … … …
Expand All @@ -28,11 +33,20 @@ The basic building block of an ontology is a hierarchy of concepts. Higher nodes
Optic nerve Heathrow airport


Just a tree of arbitrary labels isn't particularly useful. That's why ontologies may have some of the following features.
<sumo> is a big, well-known upper ontology. (Most of the examples here are from SUMO, but the general concepts of taxonomy, relationships etc. aren't limited to SUMO.)

## Taxonomy

The basic building block of an ontology is a hierarchy of concepts (or "terms"). Higher nodes represent general concepts, lower nodes more specific. For example, see the tree above.

Depending on the ontology, the concepts may be classes, individuals (or "particulars"), properties or any of the following (and probably tons of other things I have missed). Quote from Mascardi et al. (2007) [A Comparison of Upper Ontologies](http://personales.upv.es/prosso/resources/MascardiEtAl_WOA07.pdf), comparing SUMO and DOLCE:

> DOLCE has been carefully crafted with respect to strong principles. DOLCE is an “ontology of particulars”; it does have universals (classes and properties), but the claim is that they are only employed in the service of describing particulars. In contrast, SUMO could be described as an ontology of both particulars and universals. It has a hierarchy of properties as well as classes. This is a very important feature for practical knowledge engineering, as it allows common features like transitivity to be applied to a set of properties, with an axiom that is written once and inherited by those properties, rather than having to be rewritten, specific to each property.

(TODO: is the distinction Individual vs. Class meaningful? Or does it depend on the ontology?)
No matter what kind of entities they are, just a tree of arbitrary labels isn't particularly useful. That's why ontologies may have some of the following features.

### Relationships
## Relationships

So far we've seen only taxonomy membership in a strict tree structure.
* Spice Girls `is-a` Band
Expand All @@ -48,12 +62,12 @@ Furthermore, the relation links themselves can be the subject or object in anoth

See [RDF](https://en.wikipedia.org/wiki/Resource_Description_Framework), a data model based on subject--predicate--object triples.

#### Axioms
### Axioms / Assertions / Theories / Facts / Rules

Depending on the language of the ontology, it may be possible to express more complex rules and relationships. For example, <sumo> is written in SUO-KIF which corresponds to first order logic. TODO: does the word __axiom__ mean the same in all ontologies, or is a <sumo> axiom different from an <owl> axiom?
Depending on the language of the ontology, it may be possible to express more complex relationships between the concepts. Depending on the ontology, these may be called with a variety of names. <sumo> uses the term _axioms_; [Cyc](http://slor.sourceforge.net/e_ocyc.htm) uses _theories_ and _facts_.


### Mapping to lexical resources
## Mapping to lexical resources

[Niles and Pease (2003)](http://www.adampease.org/professional/Niles-IKE.pdf) map mid-level entries from <sumo> to <wordnet>. WordNet itself has some relations like synonymy and hypernymy, and I'm not quite sure how they work together with the relations of an ontology (TODO: read the whole 2003 paper).

Expand Down
17 changes: 5 additions & 12 deletions spreadsheets_for_law.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,30 +2,23 @@
date: "2020-06-15"
tags:
- concept
- approach
---

# Spreadsheets for law

## Jason's Version

Note that "spreadsheets for law" is different from "logical spreadsheets" (which should have its own zettel).
# "Spreadsheets for law"

"Spreadsheets for Law" is the short name used to describe an argument by analogy.

In this analogy, accountants used math, and did so manually. They had the opportunity to use personal computers to automate much of those mathematical processes, but didn't, because in order to do so they would have had to learn a programming language. Then, electronic spreadsheets were invented, and within 20 years proficiency with them was considered a basic competence of the accounting profession.

By analogy, lawyers (and others) use logic, and do so manually. They have the opportunity to use computers to automate much of those logical processes, but don't, because in order to do so they would have to learn a programming langauge. If "spreadsheets for law" existed, they would see the same adoption in legal services as electronic spredsheets saw in accounting.
By analogy, lawyers (and others) use logic, and do so manually. They have the opportunity to use computers to automate much of those logical processes, but don't, because in order to do so they would have to learn a programming langauge. If "spreadsheets for law" existed, they would see the same adoption in legal services as electronic spreadsheets saw in accounting.

According to this analogy, the reason that more legal services are not automated is not because of a lack of sophistication in, for example, the programming language semantics, but because of a lack of sophistication in how the power of those tools is made available to people for whom learning a programming langauge is not a realistic ask.
According to this analogy, the reason that more legal services are not automated is not because of a lack of sophistication in, for example, the programming language semantics, but because of a lack of sophistication in how the power of those tools is made available to people for whom learning a programming language is not a realistic ask.

So it is not:
* a suggestion that legal-focussed programming should be done in a <tabular_interface> (but also doesn't exclude that possibility)
* a suggestion that spreadsheets should operate on logic as opposed to math (but also doesn't exclude that possibility, which is what is meant by "logical spreadsheets")
* a suggestion that spreadsheets should operate on logic as opposed to math (but also doesn't exclude that possibility, which is what is meant by <logical_spreadsheets>)

It is an argument that the lack of adoption of automated legal reasoning is a result of a lack of a tool that is easy enough for non-programmers to learn, and demonstrates value quickly in the learning curve, like spreadsheets did for math.

"Spreadsheets for law" is an aspirational description of what a DSL with an IDE should achieve.

Related papers:

- <introduction_to_logical_spreadsheets>
4 changes: 2 additions & 2 deletions sumo.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ tags:

# SUMO

SUMO (Suggested Upper-Merged Ontology) has the approach of _domain_ ontologies and _upper_ ontologies. Example:
SUMO (Suggested Upper-Merged Ontology) has the approach of _domain_ ontologies and an _upper_ ontology. Example:

* Top level
```
Expand Down Expand Up @@ -43,7 +43,7 @@ _Quote from Mitrović et al. (2019) [Modeling Legal Terminology in SUMO](https:/
SUMO is also translated into OWL: [http://www.adampease.org/OP/SUMO.owl](http://www.adampease.org/OP/SUMO.owl).

## Terms
(_TODO: terminology overview, how does **term** in SUMO correspond to other ontologies and other words like **concept** etc?_)
(_TODO: terminology overview, does **term** in SUMO correspond to **concept** in e.g. Cyc and DOLCE, or is there a difference?_)

The basic building blocks of SUMO (and other ontologies). All of the `CamelCased` thingies in the examples above are terms (`Entity`, `AirportsFromAtoK`, `Heathrow`, …).

Expand Down

0 comments on commit bdbdfe0

Please sign in to comment.