<lomoramic>
gkellogg: i happend today to read again through your response to arto's note in reference to pat hayes and surfaces.
<lomoramic>
you describe discussions in which the "scope" of nodes was at issue. were any of the participants aware of steele's handling of that issue with respect to identifiers and objects in lisp?
<lomoramic>
he makes clear, that "scope" and "extent" are distinct characteristics. one applied to identifiers and their relation to objects, the other applies to objects and their existence.
<lomoramic>
the discussion in the rdf realm conflates the two. much to the detriment of the results.
<tjohnson>
bendiken said: `tjohnson: btw, re: https://jira.blazegraph.com/browse/BLZG-1431, it's the SPARQL test suite that is deficient, not Blazegraph... the test suite has many deficiencies, this is only one. (@lomoramic can tell you all about them ;))`
<tjohnson>
I'm pretty sure that's not right. The problem I hit was with the `RDF::Mutable` tests; and there's an analogous test in w3c's Turtle suite. Blazegraph, by default, doesn't store the lexical value of literals at all. That's definitely off-spec, though probably justifiable for many cases.
<tjohnson>
lomoramic: I'm interested in hearing about the relevant SPARQL test(s), though :)
<bendiken>
tjohnson: it's not just Blazegraph that does that. most production stores do. Dydra does, too. anything else would be stupid.
<tjohnson>
bendiken:
<tjohnson>
"stupid" may be overstating it, but it seems like the best default
<bendiken>
the issue at hand there is whether you want a store with native (i.e., efficient) datatype representation, or a store that store uninterpreted blobs--in the latter case, meaning that all your arithmetic operators, etc, will be orders of magnitude slower.
<bendiken>
no, literally, stupid.
<bendiken>
a real database uses native representation of datatypes. a document repository stores uninterpreted strings.
<tjohnson>
there's nothing preventing you from handling both native datatypes and lexical values
<tjohnson>
this is what the definition of an RDF Literal calls for
<bendiken>
you can't have both. for Blazegraph to do what you want them to do, they'd have to store *both* the native datatype and its user-supplied lexical form.
<tjohnson>
yes
<bendiken>
I posit that would be an unreasonable and highly impractical view of the world to require or to practice.
<tjohnson>
which would be required if you have some reason to care about Literal semantics
<tjohnson>
bendiken: agreed; that's why "inlining seems like the best default"
<bendiken>
other than the test case in the SPARQL suite, there is no reason whatsoever to care about the lexical form. (cf. XML Schema Datatypes spec.)
<tjohnson>
bendiken: again, the Turtle test suite (and probably others) also have tests for differentiating lexical form
<tjohnson>
as do our tests in RDF.rb
<bendiken>
it is reasonable for things dealing with surface syntax, such as a Turtle parser, to have such tests. it is unreasonable for SPARQL to have them.
<tjohnson>
agreed
<bendiken>
as for our tests in RDF.rb, if I wrote that back in the day before I understood these things, you can shoot me.
<tjohnson>
the test failure I was hitting wasn't sparql related
<bendiken>
if it's syntax-related, it's fine. otherwise, to be reviewed.
<bendiken>
(in a parser test suite, you do want to know whether your lexer and parser gave you back "01" or "1". normalization happens at a higher level.)
<gkellogg>
For a repository spec, it may be that we need to add a “feature” for maintaining the lexical form of literals, and use that in tests. This would allow a backend using something like SPARQL::Client::Repository to not keep lexical forms.
<tjohnson>
gkellogg++
<gkellogg>
That queryable test is one I added from the SPARQL test suite when debugging that stuff.
<bendiken>
as it's in the Queryable specs, it's basically the underpinnings of SPARQL. hence I'd say that anything else than value equality is superfluous.
<bendiken>
in our Ruby implementation, it's easy enough to optionally preserve the lexical form of literals--Ruby objects are basically one big hashtable, what's one more key...
<gkellogg>
lomoramic: regarding the bnode scope question; I wasn’t on the WG when these discussions happened, and could just refer to the minutes. There may be political reasons it didn’t go forward. Asking on rdf-comments@w3.org may illicit some response from people who remember such things, or as Pat directly.
<bendiken>
...in any more efficient representation, though, the only reason to preserve lexical form is that one SPARQL test case ;)
<tjohnson>
bendiken: i really don't follow your reasoning
<tjohnson>
Concepts has a clear definition of Literals and literal equality, which you need to preserve lexical form to meet
<tjohnson>
i agree that for the majority of cases, you don't care
<tjohnson>
and it seems like the kind of choice you could make easily when setting up a datastore.
<tjohnson>
but it really has little to do with the SPARQL test case
<gkellogg>
tjohnson: you’re right that lexical equality matters in RDF, but that’s of limited value for many SPARQL engines, thus the compromise. But concepts does spend quite a bit of space on the L2V mapping, as values are also important.
<gkellogg>
In RDF.rb, IIRC, we distinguish this using #== vs #eql.
<bendiken>
which moves term equality from the lexical space to the value space.
<bendiken>
further, SPARQL semantics has notions of both value and lexical equality.
<bendiken>
so, at the moment, the way this could be stated is that RDF.rb (mostly) doesn't do D-entailment, certainly not in these test cases.
<gkellogg>
I seem to recall Andy S. trying to put together a community group to update the SPARQL test suite.
<gkellogg>
We could add D-entailment tests, as it’s supported in Literal.
<bendiken>
gkellogg: such an effort for the test suite would be *most* welcome. we will certainly join in.
<tjohnson>
<bendiken>
hopefully the next SPARQL Working Group can get to where you are with the JSON-LD work, where everything is on GitHub and somebody's actually merging pulls
<gkellogg>
+1
<bendiken>
downloading out-of-date zip files that are inconsistent with what's hosted on their website as free-floating files is very 1990s... :p
<bendiken>
gkellogg: speaking of WGs, does it look like the Credentials CG will move forward to a WG? didn't have time to track it or participate in the last month or two...
<gkellogg>
Yes, we expect it to; perhaps by TPAC.
<bendiken>
great. are you going to Hokkaido, yourself?
<gkellogg>
Seems doubful now, unless someone comes forward to subsidise my travel.
<bendiken>
I have a friend who gets to fly to all the IETF meetings as part of his job. looks like the next one is in Yokohama right after the TPAC: http://www.w3.org/2015/10/TPAC/ :P
<tjohnson>
or, if implemented, should it go elsewhere?
<tjohnson>
(i haven't looked deeply at the code there, so not sure what could be re-used)
<gkellogg>
tjohnson: no, I haven’t looked into SKOS entailment, but that is indeed the right gem for it to go into. You can enable specific entailments to apply.
<tjohnson>
perfect. thanks
<tjohnson>
I'll let you know if/when I start digging in on it
<tjohnson>
probably not until after the existing rdf-ldp tickets are closed