Clojurians Log v2
rdf
Reposting here from #announcements :
: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
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.
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'
> 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
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?
need to go AFK for 10-15mins be back soon though
Yes I remember seeing Matcha and making a mental note to revisit it after I finished my thought with igraph.
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.
At some point, I'm hoping that some common approach can be developed for bringing all these disparate query languages under the same tent.
I guess the talk you're referring to is described here:
> 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?
yes that’s the one
The idea of this protocol is to serve as an abstraction over a variety of graph implementations.
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.
But what kind of libraries or applications want that portability?
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)
Sorry for the late response. I don’t look at the Clojurians slack very frequently.
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.
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.
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.
RDF graphs make sense for many cases, but say, Datomic and Neo4j make sense for others.
There may even be advantages to viewing table-based data or web APIs using the same basic abstraction.
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.
Would this involve translating your e-a-v data into a triple store?
@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?
Yes, bringing ontologies to non-RDF systems.
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.
open world modelling assumption?
globally shared, namespaced property identifiers?
access to existing RDF vocabularies/ontologies?
Yes, the primary benefit here is I think the expressiveness of a common, public vocabulary.
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.
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.
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.
Thanks @ivan.kanak_clojurians, that was a good talk.
haha I’ve heard this story I think…
semantic web is always X years away?
He said something to the effect that he wouldn't feel right making his engineers wrap their heads around OWL.
When the head of research for Google doesn't want to subject his engineers to your technology, I think that's significant.
> 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.
This one, I guess?
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.
Thanks, I'll have to watch this.
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?
Or is that the bit you want to leave out?
That's a bit I'd like to make optional 🙂
https://www.youtube.com/watch?v=dQWcD2_FzAU#t=28m6s on 28:06
As I understand it, default logic is inconsistent with the OWA.
Well it already is optional — even in RDF. 🙂
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.
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.
The traversal functions in IGraph are directly inspired by that.
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.
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?
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
It's quite raw, and even the README is crappy.
we will forgive you having one crap readme 🙂
the others were great
Oh thanks!
If you're interested, I guess you might get some idea from the test file:
https://github.com/ont-app/prototypes/blob/master/test/ont_app/prototypes/core_test.cljc
hold on let me find something you’ll find interesting