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?

👆 1
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: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.

👍 1
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

👍 1
Eric Scott18:03:43

This one, I guess?

Eric Scott18:03:37

Thanks, I'll have to watch this.