A Script to parse the ENVO.obo environmental ontology into Scheme AtomSpace representation

[Johannes Castner]

Dear opencog friends and fellow hackers and people who are interested in ontologies etc, here is a python script I've been working on that parses the ENVO.obo ontology and prints a version of it to Scheme.

I could definitely use some help with improvements and I'll be vigorously working on it myself. Here is the first draft:

https://github.com/jac2130/obo_to_Atom_Space/blob/master/ENVO_scm.py

Basically the idea is to generalize it and build new parsers and scheme writers that parse other ontologies but that follow the same basic logic.

Hope that it is useful!

johannes

[Nil Geisweiller]

Thanks for letting us know, Johannes,

Note that opencog has Python bindings, which would allow you to create
atoms as intermediary structures as opposed to directly translate into
scheme, in case that helps.

Maybe it allows you to write atoms in scheme format, I don't know as I
do not use Python bindings, but I can recall seeing code calling scheme
from python so that should be possible.

Nil

> --
> You received this message because you are subscribed to the Google
> Groups "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to opencog+u...@googlegroups.com
> <mailto:opencog+u...@googlegroups.com>.
> To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencog/25f2b3d4-83f4-4921-92d2-6dee105877a1%40googlegroups.com
> <https://groups.google.com/d/msgid/opencog/25f2b3d4-83f4-4921-92d2-6dee105877a1%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Johannes Castner]

Well, I prefer working with the scheme bindings and a light python layer that writes Scheme code. I find this to work quite well. That way the main opencog work can be done in Scheme, while code interacting with JavaScript frontends etc. and files etc, can be written in Python which deals well with websites and documents etc. there’s a lot of good libraries for website dealings in Python and for the really interesting stuff I prefer working in Scheme. So it seems that one can have the best of both worlds. Why not?

Johannes

[Johannes Castner]

Hi Nil,

So last week I was focused mainly on building a comprehensive parser that uses python and correctly parses the envo.obo code from the environmental ontology and then sends correctly parsed statements to a python class, named schemeWriter. I essentially reworked this code substantially: https://github.com/opencog/agi-bio/blob/master/knowledge-import/GO_scm.py

What I changed was first and foremost that I packed the code into three classes: for 1) loading the data 2) processing it and 3) writing scheme Atom Space representations onto a file (alternatively it wouldn't be hard to enter incoming statements directly into the AtomSpace via Python writing string representations of Scheme code.  This works brilliantly via the python interface to opencog. 

Last week I repackaged the GO_scm.py code and then I focused hard on catching all cases and parsing them correctly for the schemeWriter to then do the writing. I built a basic version of the loader, the processor and the writer and I perfected the loading and processing, while leaving most of the writing a bit coarse and wrong.  Now, I will start working more on the writing part and there it is now important to correctly encode those statements into Scheme Atomese.  For example, the idea of symmetry is encoded in the amusing friend example, so that the statement for a predicate being symmetric can follow that example: https://github.com/opencog/opencog/blob/master/examples/pln/amusing-friend/kb.scm

;; Friendship is symmetric
(ImplicationScope (stv 1 1)
   (VariableList
      (TypedVariable
         (Variable "$X")
         (Type "ConceptNode"))
      (TypedVariable
         (Variable "$Y")
         (Type "ConceptNode")))
   (Evaluation
      (Predicate "will-be-friends")
      (List
         (Variable "$X")
         (Variable "$Y")))
   (Evaluation
      (Predicate "will-be-friends")
      (List
         (Variable "$Y")
         (Variable "$X"))))
   

In the Relation Ontology which is loaded into the Sustainable Development Goals ontology that I'm working with, we have some 51 propertyChainAxioms with complex definitions like this: http://www.ontobee.org/ontology/RO?iri=http://purl.obolibrary.org/obo/RO_0002428

Do you know of a simpler way than to hand-code those Axioms individually? I mean, do you know if they might not already be encoded somewhere?  If I have to, I'll encode all of them by hand--quite a project!

Johannes

[Linas Vepstas]

Two short, perhaps useless comments:

On Fri, Jan 18, 2019 at 7:13 AM Johannes Castner <jac...@gmail.com> wrote:

 3) writing scheme Atom Space representations onto a file

The long-term vision is that you wouldn't use files; you would just poke stuff into the atomspace, and it would still be there tomorrow and they day after, even after turning the power on and off.

At the current time, you have to be a rocket surgeon to do this: configure postgresql, figure out how to use it from the atomspace, type in the magic incantation to make it go.  We haven't yet figured out how to make this trivial and fun-to-use.

 

;; Friendship is symmetric
(ImplicationScope (stv 1 1)
   (VariableList
      (TypedVariable

 

Do you know of a simpler way than to hand-code those Axioms individually?

This is a different problem we have not yet figured out how to solve.  Atomese was designed to make it easy for algos, such as PLN, to manipulate it.  As a result, it can be very verbose and hard to read.  Kind-of-like hand-writing postscript to draw a pretty picture. Postscript is great for printers and PDF's, just not for people.

If you are a rocket-surgeon, you can roll-your-own tools. Which is hard. But let me give an example:

; First, some gobbldey-gook cryptic boilerplate:

(define (var name)  (TypedVariable (Variable name) (Type "ConceptNode")))

(define (relation pname va vb) (Evaluation  (Predicate pname)  (List va vb)))

(define (axiom va vb p q) (ImplicationLink (VariableList va vb) p q))

; Now for the human-readable stuff:

(axiom (var "X") (var "Y")
     (relation "will be friends" (var "X") (var "Y"))
     (relation "will be friends" (var "Y") (var "X")) )

which is a whole lot more readable.  If you are a clever programmer, you can make "relation" take a variable number of arguments.  If you are a clever programmer, you can get rid of the need for the variable declarations. It makes the gobbldey-gook boilerplate wayyy more complicated, harder to read and understand, but it makes writing the axioms a lot easier.

One of the early opencog chatbots used perl to translate from axioms, written in a super-easy markup language, into the verbose atomese that the atomspace needed.  I know people love to hate perl, but for tasks like this, it makes them incredibly easy, easier than any other programming language I know.

-- Linas

--

cassette tapes - analog TV - film cameras - you

[Nil Geisweiller]

On 1/18/19 3:12 PM, Johannes Castner wrote:
> Do you know of a simpler way than to hand-code those Axioms
> individually? I mean, do you know if they might not already be encoded
> somewhere?  If I have to, I'll encode all of them by hand--quite a project!

Unfortunately I doubt such axioms are encoded anywhere.

I have intended to supplement PLN rules with higher order facts (HOF)
to, among other things, define an ontology of relationships such as

ImplicationScope (stv 1 1)
P
And
Member
P
Concept "binary"
Member
P
Concept "transitive"
ImplicationScope
VariableList X Y Z
And
Evaluation
P
List X Y
Evaluation
P
List Y Z
Evaluation
P
List X Z

so that one may directly write

Member (stv 1 1)
Predicate "be-friends"
Concept "transitive"

Then PLN would need an extra step to reason about the transitiveness of
be-friends but it would make it much more compact to encode.

These facts are planned to be placed under

https://github.com/opencog/opencog/tree/master/opencog/pln/facts

but, as you can see, only one is present ATM.

Nil

[Johannes Castner]

That is interesting; thank you!  I'm working on a visual frontend where people can fill in a simple form and it creates Atomese statements on the backend, where the probabilities are implemented as voting and prediction market institutions and where the first person who creates a statement is the market maker (if it is a market).   I'm just going to encode a bunch of logical relationships, each once in Scheme.  Then saying that predicate p is symmetric is enough, because it then routes the term "symmetric" to the chunk of Scheme code that encodes the meaning of predicate p being symmetric in Atomese and automatically creates that Scheme code.  I've set up the work; now I just must start encoding these sorts of things manually each once.  People thus will not have to encode Atomese at all; they just have to make logical statements and if they want to be reminded of what symmetric means, there will be a definition of it available for that.

Johannes

[Johannes Castner]

okay, cool, maybe I will be able to help with this!  This ontology here (https://github.com/SDG-InterfaceOntology/sdgio) seems to have as part of it a lot of ontological relations between logical statement types and definitions like this one that could be encoded in Atomese:

Definition: B occurs_in c =def b is a
  process and c is a material entity or immaterial entity&
  there exists a spatiotemporal region r and b
  occupies_spatiotemporal_region r.& forall(t) if b exists_at t
  then c exists_at t & there exist spatial regions s and
  s’ where & b spatially_projects_onto s at t& c is
  occupies_spatial_region s’ at t& s is a
  proper_continuant_part_of s’ at t

I can help be encoding those in Scheme and the ontology can then connect then to others via relations such as 'sub-property' etc. 

[Johannes Castner]

Hi Nil,

I've been working quite hard on some code that will allow to easily take any knowledge base, written either in obo or owl format and to load it into the AtomSpace. The subtle questions begin with how to encode certain assertions into the AtomSpace so that the meaning is best encoded into the Atomese logic.  For the Environmental Ontology, combined with the Sustainable Development Goals Interface Ontology we have the following relationships and I wonder if you might have some guidance for us as to how to encode them best in Scheme Atomese. Note that for each of those, we also have some properties (such as is_symmetric, is_transitive...):

has_increased_levels_of
causally_influences
positively_regulated_by
coincident_with
input_of
location_of
has_part_that_occurs_in
causally_related_to
involved_in_positive_regulation_of
involved_in_regulation_of
acts_upstream_of
spatially_disjoint_from
provides_nutrients_for
realized_in_response_to
during_which_ends
has_quality
has_output
produces
capable_of
interacts_with
has_end_location
contains_process
attached_to_part_of
involved_in
develops_into
enables
has_member
during_which_starts
regulated_by
has_participant
ends_after
has_developmental_contribution_from
bounding_layer_of
causally_upstream_of,_positive_effect
preceded_by
starts
has_part
quality_of
inheres_in_part_of
immediately_causally_upstream_of
participates_in_a_biotic-biotic_interaction_with
contributes_to
in_branching_relationship_with
causal_agent_in
disconnected_from
RO:0002495
located_in
has_disposition
depends_on
has_function
determines
trophically_interacts_with
ends_during
happens_during
part_of
participates_in
occurs_in
causally_downstream_of_or_within
part_of_structure_that_is_capable_of
RO:0002225
drains
directly_regulates
surrounded_by
formed_as_result_of
tributary_of
has_condition
has_active_participant
contained_in
results_in_expansion_of
has_potential_to_directly_develop_into
biomechanically_related_to
causally_upstream_of_or_within
connected_to
determined_by_part_of
results_in_transformation_into
partially_surrounded_by
biotically_interacts_with
disposition_of
developmentally_preceded_by
has_habitat
capable_of_negatively_regulating
developmentally_related_to
actively_participates_in
PATO:0005016
involved_in_negative_regulation_of
enables_activity_in
molecularly_controls
ends_with
precedes
results_in_formation_of
continuous_with
mereotopologically_related_to
determined_by
starts_with
surrounds
positively_regulates
developmentally_contributes_to
related_via_dependence_to
causally_influenced_by
adjacent_to
spatially_coextensive_with
temporally_related_to
role_of
partially_overlaps
realized_in
regulates_(processual)
acts_upstream_of_or_within
has_causal_agent
has_developmental_potential_involving
capable_of_positively_regulating
causal_relation_between_material_entities
realizes
derives_into
encompasses
member_of
RO:0009001
FOODON:00001303
has_part_structure_that_is_capable_of
ecologically_related_to
enabled_by
ends
causally_upstream_of,_negative_effect
overlaps
produced_by
developmentally_succeeded_by
has_input
immediately_causally_downstream_of
has_potential_to_develop_into
contains
connects
starts_during
results_in_proliferation_of
involved_in_or_involved_in_regulation_of
causal_relation_between_processes
bearer_of
immediately_preceded_by
derives_from
capable_of_regulating
has_start_location
has_role
immediately_precedes
FOODON:00002420
composed_primarily_of
distributary_of
capable_of_part_of
causally_upstream_of
functionally_related_to
causal_relation_between_material_entity_and_a_process
negatively_regulates
towards
molecularly_interacts_with
negatively_regulated_by
output_of
inheres_in
causally_downstream_of
results_in_developmental_progression_of
function_of
acquires_nutrients_from
attached_to
has_potential_to_developmentally_contribute_to
develops_from

On Monday, January 21, 2019 at 8:50:10 AM UTC, Nil wrote:

[Johannes Castner]

PS:

Here's a list of obo defined properties on relationships: https://metacpan.org/pod/OBO::Core::RelationshipType#is_cyclic

While obo ontologies have assert whether a relationship has one or more of these properties, it doesn't really rigorously or logically define these properties in terms of their logical meaning (only true or false).  Of course, that is something that the AtomSpace allows for that is missing from ontologies.  Thus this is something I'd like to rigorously encode.  Of course, these properties are not going to be enough to exhaustively define a relationship, but maybe they're a great way to start.  To make clear why they don't exhaustively define relationship types, let me give an example; the relationship is_married-to is defined by a number of things: who can be married? In most places on earth, two adult human beings (not 5 or 1, but 2, not children) and in some places one of them has to be a woman and the other, a man, where this really depends on the context.  But knowing who or what can be involved in a relationship (sometimes included in an ontology as range and domain) and the fact that it is symmetric etc isn't enough to define this relationship either!  Also important, to stick with is_married_to as an example, are what it implies about roles etc, and that it is likely, after being recently married to have children (either to adopt them or to have them via birth of the woman) and also that it is an expression of love, a commitment etc.  ...now, every relationship has these aspects; some are ontological in nature, some imply further things and others are part of the legal code or pertain to the nature of these relationships and natural law. Each relationship could be encoded in these ways in the AtomSpace correct?

Johannes 

[Linas Vepstas]

On Fri, Feb 1, 2019 at 9:14 AM Johannes Castner <jac...@gmail.com> wrote:

PS:

Here's a list of obo defined properties on relationships: https://metacpan.org/pod/OBO::Core::RelationshipType#is_cyclic

 Each relationship could be encoded in these ways in the AtomSpace correct?

I'm not sure I can add anything useful or meaningful here, other than to say "Yayy!" and "good job!"

Designing a good format for representing relationships is ... hard. Typically, you have a bunch of different ways you can do it, but its hard to say which is better till you try a few. So try a bunch of different prototypes, and see what works.

Some day (in the distant future!?) when you think you know of really good ways of doing relationships, it should be boiled down to a couple of examples. Ideally something that is so short and simple, we could stick it into the examples folder.... (like the ones here:  https://github.com/opencog/atomspace/tree/master/examples)  I'd be interested in seeing what they look like

--linas

[Nil Geisweiller]

Hi Johannes,

as you already know the default way to represent relationships is via
using predicates

Evaluation
Predicate "my-relationship"
List
<arg-1>
...
<arg-n>

though recently Linas has enabled the following as well

Evaluation
Predicate "my-relationship"
<arg-1>
...
<arg-n>

I don't know if there is a preferred way. I suppose if the same
argument tuples are involved with multiple predicates you may prefer
to wrap them in List so same space.

Equivalently concepts can be used where ConceptNode is to
PredicateNode and MemberLink is to EvaluationLink, it's up to you,
though I noticed people tend to use predicates for relationships and
concepts for members.

Other than that there are indeed specialized atom types that can be
used. Perhaps I would recommend that you use predicates for everything
and link them to specialized atom types during post
processing/reasoning.

To discover the many specialized atom types you may found a partial
list here

https://wiki.opencog.org/w/Category:Atom_Types

In particular, causality and spatio-temporal relationships should
ultimately be representable by specialized atom types. I know progress
is being made on that front which I haven't followed. See for instance

https://github.com/opencog/opencog/blob/master/opencog/spacetime/atom-types/atom_types.script

Nil

> --
> You received this message because you are subscribed to the Google
> Groups "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to opencog+u...@googlegroups.com
> <mailto:opencog+u...@googlegroups.com>.
> To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/7b70d209-d4b4-438d-a424-816abc8f170d%40googlegroups.com
> <https://groups.google.com/d/msgid/opencog/7b70d209-d4b4-438d-a424-816abc8f170d%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Nil Geisweiller]

Yes it could but not out of the box.

Temporal relationships are still a WIP, even in terms of their formal
definitions, but in the end you should be able to write something like

(PredictiveImplicationLink (stv 0.6 0.4)
(Predicate "married")
(Predicate "have-children-together"))

Well, the following page I wrote a while ago has a formal definition

https://wiki.opencog.org/w/PredictiveImplicationLink

but things have evolved which again I haven't followed.

I'm longing to go back to spatio-temporal reasoning but I'm involved
with other matters.

Linas, Amen? Any idea of how this is going?

Nil

> --
> You received this message because you are subscribed to the Google
> Groups "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to opencog+u...@googlegroups.com
> <mailto:opencog+u...@googlegroups.com>.
> To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/70a2842d-5c2d-4754-a79a-4cf9e4b28856%40googlegroups.com
> <https://groups.google.com/d/msgid/opencog/70a2842d-5c2d-4754-a79a-4cf9e4b28856%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Linas Vepstas]

On Sat, Feb 2, 2019 at 4:03 AM 'Nil Geisweiller' via opencog <ope...@googlegroups.com> wrote:

I'm longing to go back to spatio-temporal reasoning but I'm involved
with other matters.

Linas, Amen? Any idea of how this is going?

Seems to be dead in the water.  Anyway, all that I was plumping for was not really "reasoning" but just simple predicates that converted tow 3D points into "in front of", "behind", "next to" and if the 3D points arrived at different times, "before", "after", just so that natural language would get access to the 3D info. That's all; its pretty minimal.

Perhaps relevant for Johannes is the "electrical part of" demo, which shows how to convert a Concept into a Predicate  (and how to build complex relations out of simple ones)

https://wiki.opencog.org/w/EquivalenceLink

-- linas

[Johannes Castner]

Thank you, Linas! 

Let me ask you this: how much of the work in this book has been implemented as part of opencog, thus far: https://link.springer.com/book/10.2991/978-94-91216-11-4

Is the work on this set of ideas dead in the water or is this actively pursued and lastly, may we help with it?  We're definitely eager to help where we can, as we're trying to build on these ideas.

Johannes

[Linas Vepstas]

Hi Johannes,

On Sat, Feb 2, 2019 at 10:26 AM Johannes Castner <jac...@gmail.com> wrote:

Thank you, Linas! 

Let me ask you this: how much of the work in this book has been implemented as part of opencog, thus far: https://link.springer.com/book/10.2991/978-94-91216-11-4

I don't know; Nil would know more. I don't believe that book is being used as a literal blueprint, but rather more as a general inspiration. (I could be mistaken)

I've mostly stayed away from reasoning, but it is sort-of coming up as almost my #1 priority, so I plan to get active in it very soon now, once I clear my plate of assorted half-finished projects.
 

Is the work on this set of ideas dead in the water or is this actively pursued and lastly, may we help with it?  We're definitely eager to help where we can, as we're trying to build on these ideas.

The "dead in the water" comment applied only to the space-time server API.  The specific issue there is that the space-time server can get 3D+time coordinates from external sources (video cameras, piped through tensorflow or whateverr whizzy software does image stuff these days, which extracts 3D positions and extents, maybe some object-type labels, and pumps them, 30 frames a second, into ROS nodes (ROS==robot operating system)  ROS has a fairly rich infrastructure for this kind of stuff (self-driving cars, yada yada), so its good for sensing, tracking, SLAMming, etc. tasks.

The opencog spaceserver can cooperate with ROS to get those 3D coords. That part is done. The very next step is to implement basic "common-sense" prepositions: above, below, behind, next-to, near, far, left-of, right-of, closer, farther...(it is a finite list: there are a rigidly fixed number of prepositions in the English language).  The goal of having prepositions is to allow a natural language chatbot to talk about what is sees.  (or hears...)  This is a sideways to "reasoning" -- its more about knowing, and chatting about what you know.

-- Linas

 

Johannes

On Saturday, February 2, 2019 at 3:09:54 PM UTC, linas wrote:

On Sat, Feb 2, 2019 at 4:03 AM 'Nil Geisweiller' via opencog <ope...@googlegroups.com> wrote:

I'm longing to go back to spatio-temporal reasoning but I'm involved
with other matters.

Linas, Amen? Any idea of how this is going?

Seems to be dead in the water.  Anyway, all that I was plumping for was not really "reasoning" but just simple predicates that converted tow 3D points into "in front of", "behind", "next to" and if the 3D points arrived at different times, "before", "after", just so that natural language would get access to the 3D info. That's all; its pretty minimal.

Perhaps relevant for Johannes is the "electrical part of" demo, which shows how to convert a Concept into a Predicate  (and how to build complex relations out of simple ones)

https://wiki.opencog.org/w/EquivalenceLink

-- linas

--

cassette tapes - analog TV - film cameras - you

--

You received this message because you are subscribed to the Google Groups "opencog" group.

To unsubscribe from this group and stop receiving emails from it, send an email to opencog+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

Visit this group at https://groups.google.com/group/opencog.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/479c8040-a764-410d-b3f8-acb9967b357b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Nil Geisweiller]

On 2/2/19 6:26 PM, Johannes Castner wrote:
> Let me ask you this: how much of the work in this book has been
> implemented as part of opencog, thus far:
> https://link.springer.com/book/10.2991/978-94-91216-11-4

If you're talking about part III of the book, not much. However PLN
relies now on a much more powerful tool, the URE. At the time of writing
the book, PLN was hard-coded in C++ and somewhat inflexible.

Back then it had
- Extensional and intensional reasoning
- A bit of contextual reasoning
- Maybe some embryonic causal/spatio/temporal reasoning
- No dynamic control mechanism

The new PLN has
- Extensional reasoning
- No/broken intensional reasoning
- No/broken contextual reasoning
- No causal/spatio-temporal reasoning
- Dynamic control mechanism, capable of meta-learning. :-)

What we have gained is that OpenCog is able to learn how to control its
own reasoning and even rewrite its own reasoning rules. The counterpart
is that we still need to port intensional, contextual, causal and
spatio-temporal reasoning.

If you're interested, there is an example of control meta-learning

https://github.com/opencog/opencog/tree/master/examples/pln/inference-control-learning

Nil

> Is the work on this set of ideas dead in the water or is this actively
> pursued and lastly, may we help with it?  We're definitely eager to help
> where we can, as we're trying to build on these ideas.
>
> Johannes
>
>
> On Saturday, February 2, 2019 at 3:09:54 PM UTC, linas wrote:
>
>
>
> On Sat, Feb 2, 2019 at 4:03 AM 'Nil Geisweiller' via opencog
> <ope...@googlegroups.com <javascript:>> wrote:
>
>
> I'm longing to go back to spatio-temporal reasoning but I'm involved
> with other matters.
>
> Linas, Amen? Any idea of how this is going?
>
>
> Seems to be dead in the water.  Anyway, all that I was plumping for
> was not really "reasoning" but just simple predicates that converted
> tow 3D points into "in front of", "behind", "next to" and if the 3D
> points arrived at different times, "before", "after", just so that
> natural language would get access to the 3D info. That's all; its
> pretty minimal.
>
> Perhaps relevant for Johannes is the "electrical part of" demo,
> which shows how to convert a Concept into a Predicate  (and how to
> build complex relations out of simple ones)
>
> https://wiki.opencog.org/w/EquivalenceLink
> <https://wiki.opencog.org/w/EquivalenceLink>
>
> -- linas
> --
> cassette tapes - analog TV - film cameras - you
>

> --
> You received this message because you are subscribed to the Google
> Groups "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to opencog+u...@googlegroups.com
> <mailto:opencog+u...@googlegroups.com>.
> To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/479c8040-a764-410d-b3f8-acb9967b357b%40googlegroups.com
> <https://groups.google.com/d/msgid/opencog/479c8040-a764-410d-b3f8-acb9967b357b%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johannes Castner]

Hi Nil,

Fascinating indeed!

What is the status of the pattern miner and the interestingness measure?  I'm not asking because I'm in a rush (I still have about two weeks before I'm ready), before I can use it for my dissertation paper, I still have work to do with respect to the AtomSpace representation of the ontologies and also with auto-scaling of my system's memory so that I can load in the Gazetteer, which is huge.  I think that in about two weeks, I'd like to give that interesting pattern mininer a spin on the AtomSpace filled with two ontologies along with a huge, global gazetteer, if I can.  Gdelt might also be an interesting source of knowledge to learn new things about Sustainable Development from (https://www.gdeltproject.org/).  In the meantime, I'm working on encoding as much about those relationships as there is information for in the ontology: if a relationship is transitive, symmetric, etc. I want to at least encode that in addition to the Evaluation PredicateNode construct, which I understand, but I think that coding more of the correct structure will help to gain better insight. In the medium term, I'd be interested in seeing if the full social-cultural-institutional meaning of particular types of relations (what do they predict, etc.) could emerge from intense online interactions between people and the AtomSpace.  That is what I'm working towards academically, while trying to make use of it for business so that I can finance the operation.     

Johannes

[Nil Geisweiller]

Hi Johannes,

I'm in the debugging phase of porting Shujing's I-surprisingness code
https://wiki.opencog.org/w/Measuring_Surprisingness to the new pattern
miner (struggling against what seems to be a pattern matcher bug ATM).

In parallel I'm reviewing the literature on surprisingness and writing a
document to go beyond that code. It seems surprisingness is not only
relative to the knowledge available but also to how someone "thinks"
about something. So far I have come to the conclusion that, in its most
abstract form, surprisingness is merely the distance between the
outcomes of 2 inferences, and all specializations of surprisingness can
be derived from that abstraction. We'll see how that goes.

Porting Shujing's code will be for sure ready within 2 weeks. Going
beyond that code is gonna take a lot more time as it is research.

Nil

> > an email to opencog+u...@googlegroups.com <javascript:>
> > <mailto:opencog+u...@googlegroups.com <javascript:>>.

> > To post to this group, send email to ope...@googlegroups.com

> <javascript:>
> > <mailto:ope...@googlegroups.com <javascript:>>.

> > Visit this group at https://groups.google.com/group/opencog

> <https://groups.google.com/group/opencog>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/opencog/479c8040-a764-410d-b3f8-acb9967b357b%40googlegroups.com
> <https://groups.google.com/d/msgid/opencog/479c8040-a764-410d-b3f8-acb9967b357b%40googlegroups.com>
>
> >

> <https://groups.google.com/d/msgid/opencog/479c8040-a764-410d-b3f8-acb9967b357b%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/opencog/479c8040-a764-410d-b3f8-acb9967b357b%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to opencog+u...@googlegroups.com
> <mailto:opencog+u...@googlegroups.com>.
> To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/9f7b0614-8f4e-424f-8db8-5f1e45659cf9%40googlegroups.com
> <https://groups.google.com/d/msgid/opencog/9f7b0614-8f4e-424f-8db8-5f1e45659cf9%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johannes Castner]

Hi Nil,

If I can help you with that I would love to!  I'm trying to put that third chapter of my dissertation together and anything that pushes the envelop a bit further is always better!

Johannes

To unsubscribe from this group and stop receiving emails from it, send an email to opencog+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

Visit this group at https://groups.google.com/group/opencog.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/e166952f-2e3b-6c33-18b8-e920d1c964cf%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Johannes

--------------------------------------------------------------------------------------------------------
"Peace cannot be kept by force; it can only be achieved by understanding."

- Albert Einstein

[Nil Geisweiller]

On 2/4/19 3:48 PM, Johannes Castner wrote:
> If I can help you with that I would love to!  I'm trying to put that
> third chapter of my dissertation together and anything that pushes the
> envelop a bit further is always better!

Sure, I'll keep you informed of my progress, any help is welcome!

Nil

> <mailto:opencog%2Bu...@googlegroups.com> <javascript:>
> >      > <mailto:opencog+u...@googlegroups.com
> <mailto:opencog%2Bu...@googlegroups.com> <javascript:>>.

> >      > To post to this group, send email to

> ope...@googlegroups.com <mailto:ope...@googlegroups.com>
> >     <javascript:>
> >      > <mailto:ope...@googlegroups.com

> <mailto:ope...@googlegroups.com> <javascript:>>.
> >      > Visit this group at https://groups.google.com/group/opencog
> >     <https://groups.google.com/group/opencog>.
> >      > To view this discussion on the web visit
> >      >
> >
> https://groups.google.com/d/msgid/opencog/479c8040-a764-410d-b3f8-acb9967b357b%40googlegroups.com
> >
>  <https://groups.google.com/d/msgid/opencog/479c8040-a764-410d-b3f8-acb9967b357b%40googlegroups.com>
> >
> >      >
> >
>  <https://groups.google.com/d/msgid/opencog/479c8040-a764-410d-b3f8-acb9967b357b%40googlegroups.com?utm_medium=email&utm_source=footer
> >
>  <https://groups.google.com/d/msgid/opencog/479c8040-a764-410d-b3f8-acb9967b357b%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> >
> >      > For more options, visit https://groups.google.com/d/optout
> >     <https://groups.google.com/d/optout>.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "opencog" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to opencog+u...@googlegroups.com

> <mailto:opencog%2Bunsu...@googlegroups.com>
> > <mailto:opencog+u...@googlegroups.com
> <mailto:opencog%2Bunsu...@googlegroups.com>>.

> > To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@googlegroups.com>

> > <mailto:ope...@googlegroups.com <mailto:ope...@googlegroups.com>>.

> > Visit this group at https://groups.google.com/group/opencog.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/opencog/9f7b0614-8f4e-424f-8db8-5f1e45659cf9%40googlegroups.com
>
> >
> <https://groups.google.com/d/msgid/opencog/9f7b0614-8f4e-424f-8db8-5f1e45659cf9%40googlegroups.com?utm_medium=email&utm_source=footer>.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "opencog" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to opencog+u...@googlegroups.com

> <mailto:opencog%2Bunsu...@googlegroups.com>.

> To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/e166952f-2e3b-6c33-18b8-e920d1c964cf%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Johannes
>
> --------------------------------------------------------------------------------------------------------
> "Peace cannot be kept by force; it can only be achieved by understanding."
>
> - Albert Einstein
>

> --
> You received this message because you are subscribed to the Google
> Groups "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to opencog+u...@googlegroups.com
> <mailto:opencog+u...@googlegroups.com>.
> To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/CABZZiPLHJMrzaDxCui-M4cR1jTn0XgAAJbk6tKJX7-4JnXCjVw%40mail.gmail.com
> <https://groups.google.com/d/msgid/opencog/CABZZiPLHJMrzaDxCui-M4cR1jTn0XgAAJbk6tKJX7-4JnXCjVw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Linas Vepstas]

On Mon, Feb 4, 2019 at 3:11 AM 'Nil Geisweiller' via opencog <ope...@googlegroups.com> wrote:

Hi Johannes,

I'm in the debugging phase of porting Shujing's I-surprisingness code
https://wiki.opencog.org/w/Measuring_Surprisingness to the new pattern
miner (struggling against what seems to be a pattern matcher bug ATM).

What's the bug? I encourage open discussion first; it can sometimes help avoid wasting time on dead-ends.

-- linas

[Nil Geisweiller]

Hi Linas,

On 2/6/19 10:53 PM, Linas Vepstas wrote:
> What's the bug?

The pattern matcher fails to consider some candidates if they have
been added before some rule-engine call. I wonder if it is another
manifestation of

https://github.com/opencog/atomspace/issues/1921

which, if so, means it goes even deeper than the pattern matcher.

> I encourage open discussion first; it can sometimes help
> avoid wasting time on dead-ends.

I totally agree, but at this point I'm still trying to narrow the
reproducability of the problem down to a minimal number of steps
before creating an issue.

Nil

>
> -- linas
>
> --
> cassette tapes - analog TV - film cameras - you
>

> --
> You received this message because you are subscribed to the Google
> Groups "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to opencog+u...@googlegroups.com
> <mailto:opencog+u...@googlegroups.com>.
> To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/CAHrUA36WY5_wXXvnuzb6arMORGgOpicteubLNfzCmBjnRX%3DaOw%40mail.gmail.com
> <https://groups.google.com/d/msgid/opencog/CAHrUA36WY5_wXXvnuzb6arMORGgOpicteubLNfzCmBjnRX%3DaOw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Linas Vepstas]

On Thu, Feb 7, 2019 at 1:33 AM 'Nil Geisweiller' via opencog <ope...@googlegroups.com> wrote:

Hi Linas,

On 2/6/19 10:53 PM, Linas Vepstas wrote:
> What's the bug?

The pattern matcher fails to consider some candidates if they have
been added before some rule-engine call. I wonder if it is another
manifestation of

https://github.com/opencog/atomspace/issues/1921

which, if so, means it goes even deeper than the pattern matcher.

I doubt it. 

If you add (or remove) atoms *during* a pattern match, then yes, it might get confused, and not spot them. But if they are added *before* the match is started, then it should "just work".

Using multiple atomspaces can easily lead to confusion: if you add atoms to some temp atomspace (that you are managing yourself), and you thought you put them elsewhere, then of course you won't find them where you think you might have put them.

Also: the pattern matcher keeps a stack of temporary atomspaces, pushing when it moves forward, and popping them (clearing them) when it backtracks. The goal is not to pollute search results in one excursion with temp atoms created in another excursion.  If your newly created atoms are somehow being created in one of these temp atomspaces, then they will disappear as soon as the pattern matcher finishes.

--linas

[Johannes Castner]

Hi Nil,

How is the interesting pattern-miner doing these days?  I'm getting closer and closer to the point where I'd love to run it on some things. 

Hope you're doing well!

Johannes

[Nil Geisweiller]

Hey,

I have ported Shujing's I-Surprisingness to the new pattern miner and
I'm generalizing it for patterns with partial linkage between clauses.
The problem with Shujing's code is that it only works with fully
connected clauses like

And
P(X,Y)
Q(X,Y)

but not with partially connected ones like

And
P(X,Y)
Q(Y,Z)

usually rating these as more surprising than they are. I except to have
something ready by the end of the week. It won't be the grand theory of
surprisingness we'll eventually have to converge to, but it should be
good enough to filter out a big class of obviously unsurprising patterns.

Nil

> > an email to opencog+u...@googlegroups.com <javascript:>
> > <mailto:opencog+u...@googlegroups.com <javascript:>>.

> > To post to this group, send email to ope...@googlegroups.com

> <javascript:>
> > <mailto:ope...@googlegroups.com <javascript:>>.

> > Visit this group at https://groups.google.com/group/opencog

> <https://groups.google.com/group/opencog>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/opencog/CAHrUA36WY5_wXXvnuzb6arMORGgOpicteubLNfzCmBjnRX%3DaOw%40mail.gmail.com
> <https://groups.google.com/d/msgid/opencog/CAHrUA36WY5_wXXvnuzb6arMORGgOpicteubLNfzCmBjnRX%3DaOw%40mail.gmail.com>
>
> >

> <https://groups.google.com/d/msgid/opencog/CAHrUA36WY5_wXXvnuzb6arMORGgOpicteubLNfzCmBjnRX%3DaOw%40mail.gmail.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/opencog/CAHrUA36WY5_wXXvnuzb6arMORGgOpicteubLNfzCmBjnRX%3DaOw%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>
> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to opencog+u...@googlegroups.com
> <mailto:opencog+u...@googlegroups.com>.
> To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/e4aa2518-e6cc-4ee6-94e4-45c753961a80%40googlegroups.com
> <https://groups.google.com/d/msgid/opencog/e4aa2518-e6cc-4ee6-94e4-45c753961a80%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johannes Castner]

Fantastic, thank you!   This is an information theoretic measure of surprise right? 

Is it related the the Jenson-Shannon Divergence?  Is there a paper on it?

Johannes

[Michael Duncan]

hi johannes, i helped write some of the (now mostly outdated) code in the agi-bio repo.  i've been following this conversation but have been too busy working on a gene annotation service that includes a new version of the atomspace representation and import scripts for the gene ontology that we are contributing to the snet beta release to chime in.  once the snet service version is finalized we will update the agi-bio repo with the new code so you can access it there or on the snet repo for the service. unfortunately i haven't had a chance to look over what you've done so far to compare but hopefully you'll be willing to discuss it with us in the singularity net bio community forum we will launch with the beta.

also, unless i missed it, nil forgot to mention that he wrote an import script for sumo, which i'm assuming is the Suggested Upper Merged Ontology (there isn't a direct reference in the readme).

thanks for sharing!

 

On Monday, January 14, 2019 at 8:49:02 AM UTC-5, Johannes Castner wrote:

Dear opencog friends and fellow hackers and people who are interested in ontologies etc, here is a python script I've been working on that parses the ENVO.obo ontology and prints a version of it to Scheme.

I could definitely use some help with improvements and I'll be vigorously working on it myself. Here is the first draft:

https://github.com/jac2130/obo_to_Atom_Space/blob/master/ENVO_scm.py

Basically the idea is to generalize it and build new parsers and scheme writers that parse other ontologies but that follow the same basic logic.

Hope that it is useful!

johannes

[Johannes Castner]

Hi Michael,

I'd be super happy to discuss and to help out anywhere I can!  I'm trying to build on an effort called `pronto' that allows merging of owl and obo ontologies and that helps with a lot of the parsing, pre-processing and most importantly, intelligent information bundling, in preparation of inserting it into the AtomSpace in the most meaning preserving and enhancing ways possible.  I'm currently trying to add a feature that would allow for intelligent JSON-LD handling; so that ConceptNet and SciGraph can be handled by the same tools that allow you to also handle obo and owl ontologies (there is a one-to-one mapping between all of those formats): https://scigraph.springernature.com/explorer/api/   I'd love to know if such tools could help you!

Johannes   

[Hedra Seid]

HI Johannes, 

This is Hedra, I work on importing different bioinformatics data set's into Atomese format for the Gene Annotation Service we are doing at MOZI-AI. Most of the datasets I used to work with were in a CSV format and I was not dealing with any of the ontology processing tools.

You can find the datasets Atomese version here https://mozi.ai/datasets/ and the scripts to import them here https://github.com/opencog/agi-bio/tree/master/knowledge-import/SNET

If you are interested in what we are doing at mozi, you can also check our github page here https://github.com/moZI-AI/  
 
Beside the datasets above, I am working to import the go-plus.owl (which contains the main GO ontology plus axioms connecting to selected external ontologies) and I have been exploring tools to process RDF or OWL/XML

data, I found pronto to be very helpful thank you for the post.

If you don't mind, I will update you once am done working with it or have a question as I believe your feedback really helps with the ontology related works we will do.

Thank you so much!

Best Regards! 

Hedra 

[Johannes Castner]

Hi Hedra,

Well, the way that I see it, there should be one tool (and I’m thinking to rework pronto for this purpose) that imports ANY ontology (RDF, turtle, obo, etc and especially JSON-LD, which is what developers prefer and what’s used in RESTFUL APIs) into the AtomSpace, regardless of its format. The point of ontologies is to be uniform and to share base vocabulary and relationships as much as possible, so that the same machines can easily merge them and use them in predictable ways. Now, if that’s true, then loading in this or the other ontology and merging those ontologies shouldn’t be a special new project for every new ontology, but it should simply be a pipeline. So in particular, to take the next ontology that you want to load into the AtomSpace should be as easy as:

scheme_router = Scheme_router(URI_of_your_next_ontology)
scheme_router.load()

And it shouldn’t matter whether that ontology is in owl, RDF, JSON-LD or any other format that expresses the same structure. Does this make sense to you?

If this tool has been built already, please let me know! If not, I’m planning on extending pronto soon (as soon as we get the opencog system working which we’re having serious issues with right now) in order to ingest JSON-LD ontologies from any random entry point (using something like breadth first search or something like that in order to grab the whole graph).


Johannes

[Hedra Seid]

HI Johannes,

Yes, It makes sense. 

As far as my knowledge, that is the longer plan but it is not yet implemented. Hence, working on such a tool is really helpful. Thanks. 

[Johannes Castner]

Fantastic; I’m having some issues now though because for some reason, unknown to me, suddenly the Python API and even the Scheme code don’t work anymore after a bug fix was implemented. Now I’m sitting here with all of my Python code that I’ve been working on and it’s not running. Hopefully that’ll change soon; I’m working on trying to resolve that now.

[Hedra Seid]

HI Johannes

That's great. On the mean time, I would like to share with you the script I wrote to import gene ontology (go-plus) which is in owl format. 

I used Pronto and it works fine. I have also tried to import some other owl and Obo files and it worked. 

You can find the script here 

https://github.com/MOZI-AI/owl2atomese

Your feedback's are very welcome. Thanks!