Fork me on GitHub
#rdf
<
2020-03-19
>
Eric Scott16:03:57

Reposting here from #announcements :

rickmoynihan16:03:01

:thumbsup: @eric.d.scott I’m curious what your plans for the above and the other ont-app projects. It seems like you’re taking similar approaches, or at least trying to solve some of the same problems as myself

Eric Scott16:03:18

Well, the motivation for the project is that I think there could be a really good fit between clojure's functional programming paradigm and graph-based representations that use a ontology-driven approach.

Eric Scott16:03:37

I spent several years working in Python with semantic technologies, and when I came back to Clojure, I had this feeling that S-P-O-type graphs could make a really expressive sort of 'super-map'

rickmoynihan16:03:12

> S-P-O-type graphs could make a really expressive sort of ‘super-map’ This is definitely my experience too. It’s why I wrote matcha

rickmoynihan16:03:04

Also I think other people have had similar ideas; cgrand spoke about this at clojurex last year — IIRC he called it “map fatigue”, and was suggesting datalog approaches. Obviously not a new idea, e.g. datomic/datascript particularly in the browser etc. Datalog is almost sparql though right?

👆 4
rickmoynihan16:03:57

need to go AFK for 10-15mins be back soon though

Eric Scott16:03:43

Yes I remember seeing Matcha and making a mental note to revisit it after I finished my thought with igraph.

rickmoynihan17:03:18

Main usecase matcha was made for is to provide BGP queries over in memory RDF graphs. Typically we use it to after CONSTRUCT ing a subset of graph data from the triplestore with sparql; then we throw it into a matcha graph; and query that model a bunch of times to build out a UI/tree.

Eric Scott16:03:33

I'm kind of looking for a common abstraction over a whole range of graph-based representations. Right now I'm in the early stages of sussing out an approach to neo4j.

Eric Scott17:03:43

At some point, I'm hoping that some common approach can be developed for bringing all these disparate query languages under the same tent.

Eric Scott17:03:28

I guess the talk you're referring to is described here:

rickmoynihan17:03:04

yes that’s the one

rickmoynihan17:03:02

> At some point, I’m hoping that some common approach can be developed for bringing all these disparate query languages under the same tent. This is what I don’t really understand; for what purpose?

Eric Scott17:03:00

The idea of this protocol is to serve as an abstraction over a variety of graph implementations.

rickmoynihan17:03:35

But what kind of libraries or applications want that portability?

quoll21:03:08

Naga was written specifically to be agnostic over databases like that. (The original goal was to switch between Datomic and SPARQL, and expand from there)

quoll21:03:10

Sorry for the late response. I don’t look at the Clojurians slack very frequently.

Eric Scott17:03:38

The various IFn forms allow some degree of generalization, but if you want to take a common view of datomic-based and say Wikidata-based content, you have to write datalog for one and SPARQL for the other.

Eric Scott17:03:37

The domain-driven- and behavior-driven-development folks talk a lot of about "Ubiquitous Vocabulary". A lot of what's driving my thinking here is that there could be an ontology-driven approach to development where that vocabulary takes the form of an ontology.

✔️ 4
rickmoynihan17:03:20

@eric.d.scott Sure. I don’t disagree with any of that, though I’m not sure I understand whats special about the approach. If you were doing it in an RDBMS, you’d just model the the vocabulary in tables and foreign keys. Isn’t it natural that if you were to do it in RDF you’d coin an ontology? Or do you see it more the other way round, bringing Ontologies to non-RDF systems?

Eric Scott17:03:18

Yes, bringing ontologies to non-RDF systems.

rickmoynihan17:03:07

ok cool… next question: What do you think ontologies bring to these other systems? They typically have some form of schema already — which is more or less equivalent.

rickmoynihan17:03:52

open world modelling assumption?

rickmoynihan17:03:24

globally shared, namespaced property identifiers?

rickmoynihan17:03:47

access to existing RDF vocabularies/ontologies?

Eric Scott17:03:34

Yes, the primary benefit here is I think the expressiveness of a common, public vocabulary.

👍 4
Eric Scott17:03:17

Speaking of the OWA, I wonder if a better alternative might be in many cases to just publish your close-world data as an immutable graph, then leave it to me to decide whether and how to use that data as a resource.

Eric Scott17:03:16

The hoops that OWL makes you jump through in order to support the OWA add a lot of friction to the whole process.

Eric Scott17:03:02

I remember going to a conference a few years back, and Peter Norvig was the invited speaker. The subject of RDF came up in the context of Knowledge Graphs.

rickmoynihan17:03:19

haha I’ve heard this story I think…

rickmoynihan17:03:33

semantic web is always X years away?

Eric Scott17:03:41

He said something to the effect that he wouldn't feel right making his engineers wrap their heads around OWL.

Eric Scott18:03:34

When the head of research for Google doesn't want to subject his engineers to your technology, I think that's significant.

rickmoynihan18:03:53

> Speaking of the OWA, I wonder if a better alternative might be in many cases to just publish your close-world data as an immutable graph, then leave it to me to decide whether and how to use that data as a resource. > The hoops that OWL makes you jump through in order to support the OWA add a lot of friction to the whole process. Indeed. I think in practice that’s what most people do already though. Almost all real applications want to make some closed world assumptions about the data.

rickmoynihan18:03:01

however I think OWA is useful in a modelling context. I just think you often want additional closed world constraints on the data you load.

rickmoynihan18:03:32

backing up a bit… There’s a difference between OWL and RDF though. When you speak about bringing ontologies to other systems, do you mean OWL-like reasoning?

rickmoynihan18:03:58

Or is that the bit you want to leave out?

Eric Scott18:03:21

That's a bit I'd like to make optional 🙂

Eric Scott18:03:45

As I understand it, default logic is inconsistent with the OWA.

rickmoynihan18:03:55

Well it already is optional — even in RDF. 🙂

Eric Scott18:03:21

I definitely want to leave the door open to putting whatever data you have into a triple/quad store, and firing up the reasoner, if you can tame your data to the point where everything fits together just so.

Eric Scott18:03:22

My experience with RDF was almost entirely ingesting crowd-sourced Linked Data, and my data was seldom that tame. I mostly used property paths and did my reasoning lazily.

Eric Scott18:03:43

The traversal functions in IGraph are directly inspired by that.

rickmoynihan18:03:31

Funny you should mention defeasible logics; I used to work for a company that made what was I think at the time one of the first real implementations of a defeasible reasoner — based on the logic of Henry Prakken.

rickmoynihan18:03:22

Either way it’s an interesting objection to raise against OWL. At the time we certainly had those objections to it too… IIRC our CTO felt OWL was pretty conservative. Are you actually applying or wanting to apply defeasible reasoning against your data? If so what for?

Eric Scott18:03:27

Well I'm far from the point where I'm ready to announce this yet, but I've started a project here: https://github.com/ont-app/prototypes

Eric Scott18:03:15

It's quite raw, and even the README is crappy.

rickmoynihan18:03:31

we will forgive you having one crap readme 🙂

rickmoynihan18:03:39

the others were great

Eric Scott18:03:29

If you're interested, I guess you might get some idea from the test file:

rickmoynihan18:03:38

hold on let me find something you’ll find interesting

Eric Scott17:03:34

So the idea is that you sit down with your domain expert and systematically name the pertinent set of collections and relationships, but instead of parlaying that into a set of Java classes, you use this vocabulary to describe your application state as a graph or perhaps a set of graphs.

Eric Scott17:03:25

RDF graphs make sense for many cases, but say, Datomic and Neo4j make sense for others.

Eric Scott17:03:51

There may even be advantages to viewing table-based data or web APIs using the same basic abstraction.

Ivan17:03:10

the way I view things, if you have such an encoding in RDF, you can then model -on top of it- graph relations or other types of relations. How e-a-v is ordered and indexed makes this possible.

Eric Scott17:03:11

Would this involve translating your e-a-v data into a triple store?

Ivan17:03:05

What I understand that you're talking about is a generic interface that gives you the ability to plug into different systems to manipulate the data. Which, in other words, means that the data are "viewed" in different formats by the (db) systems, but can be manipulated in other formats, too - because this generic interface allows for this. Which in turn reminds me of the "Polyglot Data" talk by Greg Young - ie, the database system is a projection of the data; data can have multiple projections but only a single source.

👍 4
Eric Scott12:03:05

Thanks @U8ZE1VBSS, that was a good talk.

Ivan12:03:17

it is mixed with the whole event-sourcing paradigm (although there is good reason for that: reducing complexity through immutability), but the concept, I think, is similar. From what I understand, you have very close goals. - Greg says that there is single source of data, and adapters expose the data in different formats through the different DBMS systems. - You say that there is a common interface; an API that allows you to talk to the different systems, as if the data bellow them had the same format. He centralizes on the data (data-first); you centralize on the interface (function-first). There are pros and cons to those choices that can make up a nice discussion. Who is lifting the weight in each case, what way provides more flexibility in case something is found to be "incompatible", etc

👍 4
Eric Scott18:03:43

This one, I guess?

Eric Scott18:03:37

Thanks, I'll have to watch this.

Ivan12:03:17

it is mixed with the whole event-sourcing paradigm (although there is good reason for that: reducing complexity through immutability), but the concept, I think, is similar. From what I understand, you have very close goals. - Greg says that there is single source of data, and adapters expose the data in different formats through the different DBMS systems. - You say that there is a common interface; an API that allows you to talk to the different systems, as if the data bellow them had the same format. He centralizes on the data (data-first); you centralize on the interface (function-first). There are pros and cons to those choices that can make up a nice discussion. Who is lifting the weight in each case, what way provides more flexibility in case something is found to be "incompatible", etc

👍 4