sorry for the delay replying @heksenlied:matrix.org
The Scala3 version is here: https://github.com/bblfish/banana-rdf/
I have been using it for a number of projects already. The core is there and pretty stable I think.
I never was happy with the old IO from banana-rdf... So I am trying to work out how to get that to work.
The projects for which I used it are listed here:
https://github.com/co-operating-systems/solid-control
I think the akka server is not using it yet, but the JS libs are.
https://github.com/co-operating-systems/solid-control
I think the akka server is not using it yet, but the JS libs are.
I will try keeping my Element open again here all day so as to catch messages a bit faster. But if it is urgent don't hesitate to send me an e-mail or a tweet message.
Alright. If the core is pretty stable, we were thinking about adding SPARQL-support to the scala-3 branch in our fork and merge it back to your main repo (might as well add it to an existing project that will need it at some point anyways 😛). Would it be possible for you to set up a pipeline for publishing the scala-3 branch to Maven Central?
I noticed
rStatement.Relation is defined as type Relation[R <: RDF] = rURI[R], and not type Relation[R <: RDF] = rURI[R] | URI[R] - is there a particular reason? Because as long as that is fixed, there seems to be no problem removing the implicit defs in Ops.scala (at least all tests compile and run successfully).
the Scala-3 branch is already published to sonatype https://oss.sonatype.org/content/repositories/snapshots/net/bblfish/rdf/
I was going to wait for it to be a bit more stable before going to Maven CEntral
I was going to wait for it to be a bit more stable before going to Maven CEntral
SPARQL support sounds good. You could go the way that we were going in the old banana-rdf.
There are many ways to do that.
I was thinking at least for the initial attempt, I'd base it on how it was done in the Scala 2 branch.
Other options I think will take much longer to think through....
I found it quite useful as it was :-)
heksesang: sorry I just saw your question
I noticed rStatement.Relation is defined as type Relation[R <: RDF] = rURI[R], and not type Relation[R <: RDF] = rURI[R] | URI[R] - is there a particular reason? Because as long as that is fixed, there seems to be no problem removing the implicit defs in Ops.scala (at least all tests compile and run successfully).
the rURI was there to build relative URIs and have relative Graphs.
ie. graphs with relative uris. By having a type we could make sure that certain operations are not permitted on them (such as unioning them).
So that would allow us to be sure the normal graphs have no relative URIs in them.
In banana-rdf we allowed those as they are very useful, but then it gets confusing
Relative Graphs are useful for LDP POST, when creating a new resource. Also sometimes you want to copy a graph with relative URLs, say from the file system, without having to know what the server url is. ...
As it is now:
object rStatement:
type Subject[R <: RDF] = rURI[R] | BNode[R] | URI[R]
type Relation[R <: RDF] = rURI[R]
type Object[R <: RDF] = rURI[R] | BNode[R] | Literal[R] | URI[R]
type Graph[R <: RDF] = rURI[R] | BNode[R] | URI[R]
end rStatementWhy is it not defined as:
object rStatement:
type Subject[R <: RDF] = rURI[R] | BNode[R] | URI[R]
type Relation[R <: RDF] = rURI[R] | URI[R]
type Object[R <: RDF] = rURI[R] | BNode[R] | Literal[R] | URI[R]
type Graph[R <: RDF] = rURI[R] | BNode[R] | URI[R]
end rStatement
It looks to me like adding
URI[R] to the Relation type has simply been forgot - or was it left out on purpose?
yep you are right. I had not yet implemented it, so I had forgotten that case. Thanks for noticing.
One could also have rLiterals, but that is very rare, so one can leave that for later. :-)
you mean in the document that opens when you use the
gh (github command line client) like this:gh browse rdf/shared/src/main/scala/org/w3/banana/RDF.scala
That is because for Quads you can have graphs in the node position I think
At least that is what I was thinking doing that, but I am not 100% sure of it. I think I got that from timbl's rdflib.js ... But I am not sure.
Got to go to a conf call for 30 min at most
Yeah. That was the one I was thinking of. Just realized while trying to port some of the implementation from the 2.x branch that
RDF.Node[R] did not result in the expected type. And there is no way to use RDF.Node[R] to get for example JenaRdf.Node.
Ah? yes, perhaps that decision needs to be looked at a lot more carefully. Can you point me to code that you are writing that I can look at? I'll see if I can put some time aside to look at the problem.
1 reply
Is the
Node definition in the RDF trait used to anything? Considering there is no way to extract it from a given RDF implementation, then it could either be removed. Or else it should be fixed, so that RDF.Node[R] returns the Node type defined in R.
This line struggles to compile because the type that it tries to return (as it did in Scala 2) is
Rdf4j.Node and not RDF.Node[Rdf4j.type] (which is odd that are not the same).
I think the Graph part in the Node definition is a mistake (and it shows that there are some tests missing). If don't think it is used. But the Node is and has operations for it https://github.com/sikt-no/banana-rdf/blob/2e9fac0034cab82f58e28a842b2f8153695fbbc9/rdf/shared/src/main/scala/org/w3/banana/operations/Node.scala
I am pretty sure I thought of that while reading TimBls rdflib.js . But it has a model that interprets the objects so that literals xsd:ints are transformed into java(script) Ints, xsd:longs into java longs, etc... and graphs are literally graph pointers.... I think there is a lot to be said for interpreting literals that way, and graphs are in a way just special types of literals.... But I think that should be thought through in an issue more carefully.
It feels as if timbl's model is one functor further along than our model which is more syntactic.
So in short set
type Node[R <: RDF] = URI[R] | BNode[R] | Literal[R]see if it compiles, add a few tests (perhaps some for PG) and continue from where you were...
Actually if you look at the git blame of that line you will find that it used to be as with banana-rdf 0.8.x based on a type hierarchy:
type Node[R <: RDF] <: Matchable = R match
case GetNode[n] => nThat may still work.
with
type GetNode[N <: Matchable] = RDF { type Node = N }
Should be quite easy. As I say, I think I just added Graph to the Note type, and then forgot to get back to deleting it.