bendiken changed the topic of #ruby-rdf to: Ruby RDF & SPARQL chat. | https://github.com/ruby-rdf/rdf | Gitter: https://gitter.im/ruby-rdf/rdf | Mailing List: https://lists.w3.org/Archives/Public/public-rdf-ruby | Twitter: @Gkellogg @bendiken @no_reply | Use http://pastebin.com for code/graph snippets. Also join #swig for general linked data and semantic web chatter. Public channel log at http://irclog.whitequark.org/ruby-rdf/
gkellogg has quit [Quit: gkellogg]
gkellogg has joined #ruby-rdf
tjohnson has joined #ruby-rdf
<tjohnson> L742 seems repetitive, yes?
<tjohnson> and removing the hash equality checks altogether passes the test suite
<tjohnson> jcoyne just beat me to it :) https://github.com/ruby-rdf/rdf/pull/232
<gkellogg> Not repetative, as hashes may be the same, but values not. But, if they’re different, checking hashes first is an earlier exit.
<tjohnson> gkellogg++ learned something today :)
<tjohnson> Starting the core group meeting
<tjohnson> gkellogg says: from now on, let's scribe meeting in something like the w3c way
<tjohnson> * gkellogg: 1.99 hit a couple of glitches along the way; but is coming along
<tjohnson> * gkellogg: we need to sort out handling for 1.99, deprecations, and 2.0 behavior
<tjohnson> * gkellogg: what is the status around that with transactions?
<tjohnson> * bendiken: semantics change, we'd have to play fast and loose
<tjohnson> * bendiken: pulled latest changes to 1.1.x "transactions" into changesets; we could backport changesets and deprecate. it may be difficult to detect the use of changesets as transactions
<tjohnson> * bendiken: consider a 'from future import *' approach
<gkellogg> tjohnson: how substantial are the changes to Repository?
<tjohnson> * bendiken: the bulk of the changes are in RDF::Repository. notion is that Repository needs to support transaction; operating on reified state of the repository.
<tjohnson> * gkellogg: repository implementations that are maintained: RDF::DO, RDF::Mongo, and RDF::AggregateRepo.
<tjohnson> * bendiken: RDF::Sesame is stale
<tjohnson> * tjohnson: RDF::Blazegraph is active, motivating these changes (and changes proposed here): https://github.com/ruby-rdf/rdf/pull/224
<tjohnson> * gkellogg: let's target transaction changes for 1.99.1, using the future pattern
<tjohnson> resolved: target transaction changes for 1.99.1, using the future pattern
<tjohnson> topic: broken links in rubyforge
<tjohnson> * bendiken: found login; will redirect to ruby-rdf.github.io as appropriate
<tjohnson> * gkellogg: we talked about the Dataset/Repository split at some point in the past; Dataset could be just a read-only repository. Loading into Repository require's Writable#load and Mutable#insert.
<tjohnson> * bendiken: could you populate on instantiation?
<tjohnson> * bendiken: could make the Dataset immutable after the `#new`
<tjohnson> * bendiken: Repository would be a higher level concept; what's the reason we wanted to make this split?
<tjohnson> * gkellogg: it's just conceptual. Dataset is an RDF concept, but Repository is not.
<tjohnson> proposal: add Dataset as a new mixin that includes Queryable; that should suit as a first cut.
<tjohnson> * bendiken: we need to include that via Future, since Dataset is already aliased to Repository
<tjohnson> resolved: Dataset as described above targeted for 1.99.1; included via Future
<gkellogg> topic: issue 193
<tjohnson> * bendiken: there ought to be a general facility with a block syntax
<tjohnson> * bendiken: that's not necessarily a requirement for 2.0
<tjohnson> * tjohnson: how does this interact with changesets?
<tjohnson> * bendiken: we should merge in the latest upgrades to transaction and tjohnson can look at how things look
<tjohnson> * gkellogg: we should capture the remainder of this discussion in the issue
<tjohnson> * tjohnson: can bendiken assign that issue to me once you're done with your side of it?
<tjohnson> * bendiken: yes.
<tjohnson> * gkellogg: this should be on hold for the time being
<gkellogg> on-hold until I have more time.
<gkellogg> issue 211
<gkellogg> tjohnson: still in progress, focused on nailing down the Raptor side; there are a couple of issues that jcoyne opened #227 which is related.
<gkellogg> … I’m trying to figure out what the changes are. The Turtle changes look good. The other readers need to be updated too.
<tjohnson> * gkellogg: will take a look at RDFa, Trig, Trix, and some of the older
<tjohnson> * tjohnson: I will spec out the minimal interface
<tjohnson> * bendiken: how are we logging the errors?
<tjohnson> * gkellogg: capturing an Array of Strings errors
<tjohnson> * tjohnson: will submit a PR for `rdf-spec`; that PR will probably not require changes for RDF::Turtle, we can discuss further on the PR
<tjohnson> * gkellogg: this issue was opened in response to https://github.com/ruby-rdf/rdf-ldp/issues/35
<gkellogg> tjohnson: Blazegraph is still a problem, without using an internal Java API.
<gkellogg> … Trying to get them to open this up.
<gkellogg> … For LDP, it’s not that important, as it only really effects Patch; PUT updates are all total-rewrites of the graph anyway.
<tjohnson> * gkellogg: the only other reason to push this is conceptual purity
<tjohnson> * bendiken: it could be quite painful externally
<tjohnson> * bendiken: we could introduce an interface and throw errors, but it can wait indefinitely
<tjohnson> resolved: put it on hold
<gkellogg> tjohnson: The original change is pretty significant for performance on inserts to Repositories/Graphs. After I opened this, it become less important due to Transactions.
<gkellogg> … But, support for this is important.
<gkellogg> … rdf-blazegraph makes this automatic and will work well.
<tjohnson> * gkellogg: target this for 1.99.1 ?
<tjohnson> * tjohnson +1. I will submit a revised PR
<gkellogg> tjohnson: I think the desired behavior is, if I have an N-Triples reader loaded, which support for content_type and symbol access, and I now require no-repy:special-rdf-ntripes; at that point, I expect my implementation to take predicdence.
<tjohnson> * gkellogg: reader `#for` support may not overlap
<tjohnson> proposal: keep the officially supported `#for` format support uniform where possible
<tjohnson> * gkellogg: might be good to handle cases like non-compliant readers
<tjohnson> * bendiken: could add quality value; but favor simply using last loaded
<tjohnson> * tjohnson: will that work for n-triples? `require 'rdf'; require 'rdf/raptor'; require 'rdf/ntriples'` works?
<tjohnson> * bendiken: yes, but potentially complicated by internal use
<tjohnson> resolved: enforce last loaded target for 1.99.1
<gkellogg> Issues: PR itself, 2) delete_insert, 3) clear.
<gkellogg> tjohnson: I was thinking of adding #clear to Transaction; if true, instead of Repo.delete(…) it would just do a clear.
<gkellogg> bendiken: Once we have a transactional backend, there should be a clear graph operation, as with SPARQL.
<gkellogg> … Everything else is a Changeset use case for batching up operations. The batching construct for 2.0 is remove/insert sets of statements.
<gkellogg> … That doesn’t support the use case of clearing a graph, which would be inefficient.
<gkellogg> bendiken: your concern isn’t so much atomicity, it’s about performance.
<gkellogg> … To the support this, you want a “clear_graph” primitive, and map operations onto backend efficiently.
<tjohnson> * gkellogg: the operations supported by a changeset are pretty much equivalent to a SPARQL 1.1 Update
<tjohnson> * bendiken: right. if you wanted to support extended semantics, you would want an Array of 2-tuples with (operation, statement)
<tjohnson> ...it would then be ordered which would have implications on implementations
<tjohnson> ...current needs are met by the transaction interface
<tjohnson> * bendiken ambivalent about merging
<tjohnson> merged. :)
<gkellogg> tjohnson: try to get Project Hydra guys to move conversations on this to this channel.
<tjohnson> * gkellogg: as noted in the PR, it is possible to match a string hash but not have the values match
<tjohnson> * gkellogg: accept the second to commits and reject the first couple
<gkellogg> I’ll pull this by hand.
<tjohnson> +1
<tjohnson> timeframe for 2.0: possibly beginning of the year; but not committing to that
<tjohnson> the 1.99 release should happen today, with release notes noting to pin to 1.1 if that seems wise
<tjohnson> * bendiken: should we start moving develop over to 2.0 after the 1.99.1 release
<tjohnson> * tjohnson: consider opening a support branch for 1.99 releases
<tjohnson> * gkellogg: that sounds good. we can base the future on how people digest 1.99 releases
<tjohnson> * gkellogg: will release 1.99 and get a message to the mailing list
<tjohnson> next meeting: monday Nov 16