Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Henry Story
@bblfish
hh
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.
Henry Story
@bblfish
(I just started a part time contract job which should allow me to work on this and other things)
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.
bblfish
@bblfish:matrix.org
[m]
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.
heksesang
@heksenlied:matrix.org
[m]
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?
heksesang
@heksenlied:matrix.org
[m]
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).
heksesang
@heksenlied:matrix.org
[m]
bblfish
@bblfish:matrix.org
[m]
hi
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
bblfish
@bblfish:matrix.org
[m]
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.
heksesang
@heksenlied:matrix.org
[m]
I was thinking at least for the initial attempt, I'd base it on how it was done in the Scala 2 branch.
bblfish
@bblfish:matrix.org
[m]
that sounds good :-)
Other options I think will take much longer to think through....
I found it quite useful as it was :-)
bblfish
@bblfish:matrix.org
[m]

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
bblfish
@bblfish:matrix.org
[m]
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. ...
heksesang
@heksenlied:matrix.org
[m]

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 rStatement

Why 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?
bblfish
@bblfish:matrix.org
[m]
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. :-)
heksesang
@heksenlied:matrix.org
[m]
bblfish: What's the deal with type Node[R <: RDF] = URI[R] | BNode[R] | Literal[R] | Graph[R]? Why isn't there a match type to get the actual node type defined in the RDF-singleton instead?
bblfish
@bblfish:matrix.org
[m]
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
heksesang
@heksenlied:matrix.org
[m]
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.
bblfish
@bblfish:matrix.org
[m]
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.
heksesang
@heksenlied:matrix.org
[m]
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).
bblfish
@bblfish:matrix.org
[m]
Thanks. I will look at that. (another conf call...)
bblfish
@bblfish:matrix.org
[m]
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
bblfish
@bblfish:matrix.org
[m]
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...

bblfish
@bblfish:matrix.org
[m]

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] => n

That may still work.

with
type GetNode[N <: Matchable] = RDF { type Node = N }
heksesang
@heksenlied:matrix.org
[m]
I'll have a look at that and see what I find out.
bblfish
@bblfish:matrix.org
[m]
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.