Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 15 11:21
    hmottestad commented #2762
  • Jan 15 11:20
    hmottestad commented #2762
  • Jan 15 11:20
    hmottestad labeled #2762
  • Jan 15 11:20
    hmottestad assigned #2762
  • Jan 15 11:19
    hmottestad opened #2762
  • Jan 15 11:13
    hmottestad synchronize #2761
  • Jan 15 11:13

    hmottestad on GH-2760-NPE-compare-literals

    GH-2760 fix comparing only cust… (compare)

  • Jan 14 23:02
    jeenbroekstra assigned #2760
  • Jan 14 23:02
    jeenbroekstra milestoned #2760
  • Jan 14 21:37
    hmottestad commented #2761
  • Jan 14 21:35
    hmottestad synchronize #2761
  • Jan 14 21:35

    hmottestad on GH-2760-NPE-compare-literals

    GH-2760 more robust tests Sign… (compare)

  • Jan 14 21:23
    hmottestad commented #2761
  • Jan 14 21:14
    hmottestad synchronize #2761
  • Jan 14 21:14

    hmottestad on GH-2760-NPE-compare-literals

    GH-2760 revert som code from be… (compare)

  • Jan 14 19:47
    hmottestad commented #2761
  • Jan 14 19:14
    hmottestad commented #2761
  • Jan 14 10:22
    damyan-ognyanov review_requested #2761
  • Jan 14 10:22
    damyan-ognyanov opened #2761
  • Jan 14 10:17

    damyan-ognyanov on GH-2760-NPE-compare-literals

    GH-2760: fixes Literals.getXsdD… (compare)

Bart Hanssens
@barthanssens
@jeenbroekstra @hmottestad I've been looking into 2609 / language tag normalization, looks like there is no option to normalize language tags when using SPARQL Update or adding statements directly via RepositoryConnection.add() instead of importing via a Rio parser
wondering if a NormalizingValueFactory could be useful, maybe extending the ValidatingValueFactory ?
Jeen Broekstra
@jeenbroekstra
I think the idea of normalizing is typically at the parser level, so if you add a statement via the API it's assumed to already have been parsed (and therefore normalized if desired).
but I can see the value of being able to call normalize for manually created values.
doesn't Literals.normalize do what you need?
jeenbroekstra @jeenbroekstra is taking a closer look at #2609
Bart Hanssens
@barthanssens
it does, though a little verbose when creating literals
I've never used it in my little projects to be honest, so not sure if it really is a big issue
Jeen Broekstra
@jeenbroekstra
I'm not really following what the exact problem in that issue to be honest. There's a test case there but when I run that it seems to work exactl as the test expects.
there's talk in that issue of "the parser" behaving differently from what Literals.normalizeLanguageTag does. Is that the core of the problem? If so, which parser are we talking about?
Jeen Broekstra
@jeenbroekstra
ah. I wonder. For Rio, we have two implementations of language normalization. One based on BCP47 (which is also what Literals.normalizeLangageTags uses), the other based on RFC3066 (which I think is an older spec). It looks as if Rio currently picks the latter as its default language tag handler. that could be where the discrepancy comes from.
I'll comment on the issue too
Bart Hanssens
@barthanssens
the way I understood it, is that one would be able to query and somewhat select if language normalization would be taken into account or not... a bit like inferred triples
Jeen Broekstra
@jeenbroekstra
ah but that's what the langMatches function is for in SPARQL, isn't it?
Bart Hanssens
@barthanssens
indeed
forgot about that one
Jeen Broekstra
@jeenbroekstra
The Rio thing was a red herring I think. The code is a little hard to follow but it does in fact pick BCP47 as its default handler for normalization. So now I'm lost on where the problem is - I've asked the OP for clarification.
(btw just realized I've been shouldering my way in on an issue that you were looking into - apologies, didn't mean to rip it out of your hands!)
Bart Hanssens
@barthanssens
no worries :-)
I was just scrolling through the issue list to see if there would be a quick win somewhere
Bart Hanssens
@barthanssens
and as usual, it took a little longer than I expected, but that's OK, learned a thing or two in the process
off to bed, c u later :-)
Jeen Broekstra
@jeenbroekstra
ttyl :)
Jeen Broekstra
@jeenbroekstra
god, so happy we don't have a gazillion html files checked in anymore for the website javadoc. Tarballs are a lot easier to handle for git....
Bart Hanssens
@barthanssens
hehe, party :-)
JervenBolleman
@JervenBolleman
@hmottestad @barthanssens @jeenbroekstra I think I recall one of you wanting to work on making the QueryBindingSet more memory efficient/performant. I am having a go at it. If you also are working on this you might at least want to pick up the new tests JervenBolleman/rdf4j@34c95e3
Jeen Broekstra
@jeenbroekstra
Hi @JervenBolleman, that sounds great! It's @hmottestad who is working on this. He's not a regular reader here in gitter I think, but have a look at eclipse/rdf4j#2715 where he's been doing some performance benchmarking.
JervenBolleman
@JervenBolleman
@jeenbroekstra thanks, I fell over the performance issue when working on my own special usecase triplestore for DNA genome variation graphs.
Jeen Broekstra
@jeenbroekstra
@JervenBolleman would you have time to propose an actual improvement PR based on the spiking that Havard did (as well as your own tests)?
JervenBolleman
@JervenBolleman
@jeenbroekstra think @hmottestad just pushed a better implementation to his branch
Jeen Broekstra
@jeenbroekstra
I think that's just a test implementation though, to "prove the point". It's not ready for merging as it oversimplifies a number of things. Hang on, I'll comment on the PR to ask how we want to proceed.
JervenBolleman
@JervenBolleman
Yeah, otherwise maybe he could run my implementation and see if that does "enough".
Jeen Broekstra
@jeenbroekstra
Could you put up your implementation as a (draft) PR as well? Makes it a bit easier to compare perhaps
JervenBolleman
@JervenBolleman
Jeen Broekstra
@jeenbroekstra
Thanks @JervenBolleman - I'm hoping Havard will find some time to coordinate with you further. I'm currently rather fully booked myself I'm afraid :(
Jeen Broekstra
@jeenbroekstra
PSA I have adjusted the spam settings a bit on the rdf4j-users google group. It doesn't offer a lot of control but hopefully we get fewer false positives this way (and therefore fewer people who try to post the same message 10 times...).
JervenBolleman
@JervenBolleman
I just wanted to say thanks to all the developers whom have made a great project over the years! Love the RDF4J code base :D and everyone whom made it possible. Thanks and enjoy the new year.
Jeen Broekstra
@jeenbroekstra
@JervenBolleman thank you, and a happy new year to you too! Very grateful to have you on board contributing to RDF4J.
Iwan Aucamp
@aucampia
hi, should I use RDF4J or Jena?
Specifically I am building some ontology based data access system
Where I get SPARQL queries and have the tripple store as a read through cache essentially
Bart Hanssens
@barthanssens
well, it is an RDF4J chat room, so ... ;-) depends on what you need, e.g. RDF4J's support for SHACL is excellent, but there is only limited support for reasoning while (if I recall correctly) Jena has a built-in OWL reasoner
both Jena and RDF4J provide triple stores, API etc
Bart Hanssens
@barthanssens
if for some reason the stores provided by RDF4J are not (fast/scalable) enough, there are other stores like Ontotext or NeptuneDB, Halyard ... that can be used with RDF4J
Bart Hanssens
@barthanssens
so I'd suggest to give RDF4J a try and if there would be any issues... feel free to ask :-)
Jeen Broekstra
@jeenbroekstra
@aucampia what Bart said. Give RDF4J a try, there's tutorials and documentation to get you going on rdf4j.org. If you run into any problems, we'll be happy to answer any questions (either here or on the mailinglist).
Iwan Aucamp
@aucampia
thanks
I guess the biggest advantage of Jena is the OWL reasoner, but it is maybe of limited value
RDFS reasoning is plenty