LeeF: I would want COUNT in Axel's example to be 2 because in the non-aggregate case you would have 2 rows that have at least one binding

12:50:43 [LeeF]

... (you have a 3rd row with no bindings)

12:51:29 [AndyS]

LeeF, you can get it withj COUNT(COALESCE(int(?x),int(?y)) -- all answers are COALESCE

12:51:47 [LeeF]

AndyS, yes, I can, it's not what my impl (or intuition) does though :)

12:52:07 [AxelPolleres]

q?

12:52:09 [LeeF]

ack AxelPolleres

12:52:10 [Zakim]

AxelPolleres, you wanted to ask on what's the status of errors in SELECT expressions

12:52:11 [AxelPolleres]

ack Axel

12:52:54 [LeeF]

For me, the semantics of COUNT involve COUNTing rows that have _something_ in it

12:53:00 [LeeF]

s/For me/LeeF: For me/

12:53:05 [LeeF]

Souri: that is like in SQL

12:53:36 [LeeF]

... it's like doing a COUNT(*) limited to the sliced multiset

12:53:50 [LeeF]

... if you do COUNT(X) in SQL and X has a null value, it's not counted

12:53:54 [AndyS]

We coudl define COUNT(?x) as single arg only

12:53:54 [LeeF]

LeeF: that's where my intuition comes from

12:53:58 [dcharbon2]

q+

12:54:22 [AxelPolleres]

OPTION 1 : FILTER view, result = 1

12:54:23 [AxelPolleres]

OPTION 2 : projection view, result = 3 (always the same as COUNT(*))

12:54:23 [AxelPolleres]

OPTION 3 : count rows with at least one unbound, result =2

12:54:31 [AxelPolleres]

q?

12:54:38 [LeeF]

ack dcharbon

12:54:48 [LeeF]

dcharbon2: tried to figure out what i thought the meaning of some of these results is

12:54:56 [AndyS]

Under option 2, COUNT(?x) == COUNT(*) ??

12:55:19 [LeeF]

... with OPTION 1: you're counting complete tuples - then you can use COALESCE to get the count of tuples with any content - you're still missing a way to get the COUNT of all tuples including empty ones

12:55:26 [LeeF]

... there are probably use cases for all 3

12:55:27 [bglimm]

As I see it, the only difference is whether something like xsd:integer(nonInteger) inserts a null/unbound value or whether it takes the row out in which nonInteger occurred

12:55:56 [SteveH]

I think you can think of them options as:

12:55:57 [SteveH]

COUNT(xsd:integer(?a) + xsd:integer(?b))

12:55:57 [SteveH]

COUNT(COALESCE(xsd:integer(?a), xsd:integer(?b)))

12:55:57 [SteveH]

COUNT(1)

12:56:03 [SteveH]

not (1)...

12:56:06 [SteveH]

that's wrong

12:56:43 [LeeF]

dcharbon2: I like OPTION 1 because I think it gives you the flexibility to do all of the approaches

q+ to suggest that we PROPOSE to resolve ISSUE-53 noting that tuples with errors are excluded from the multiset of lists passed to aggregate functions, and that the count of such excluded errors is passed to the aggregate function

13:07:23 [MattPerry]

ack me

13:07:55 [LeeF]

ack me

13:07:55 [Zakim]

LeeF, you wanted to suggest that we PROPOSE to resolve ISSUE-53 noting that tuples with errors are excluded from the multiset of lists passed to aggregate functions, and that the

13:07:56 [kasei]

so you can Sum over a single bnode?

13:07:59 [Zakim]

... count of such excluded errors is passed to the aggregate function

13:08:20 [SteveH]

kasei, good point

13:08:24 [LeeF]

PROPOSED: resolve ISSUE-53 noting that tuples with errors are excluded from the multiset of lists passed to aggregate functions, and that the count of such excluded errors is passed to the aggregate function

13:09:14 [LeeF]

SUM(_:haha) = _:haha

13:09:37 [AxelPolleres]

+

13:09:38 [sandro]

maybe SUM(X) is X-X+X :-)

13:09:38 [AxelPolleres]

+1

13:09:47 [kasei]

Sum(S) = op:numeric-add(S0, 0) when |S| = 1

13:09:50 [LeeF]

PROPOSED: resolve ISSUE-53 noting that tuples with errors are excluded from the multiset of lists passed to aggregate functions, and that the count of such excluded errors is passed to the aggregate function

13:09:58 [SteveH]

SUM(x) = op:numeric-add(x, 0)

13:10:45 [LeeF]

RESOLVED: resolve ISSUE-53 noting that tuples with errors are excluded from the multiset of lists passed to aggregate functions, and that the count of such excluded errors is passed to the aggregate function, no abstentions or objections

13:11:04 [AxelPolleres]

close ISSUE-53

13:11:04 [trackbot]

ISSUE-53 How are unbounds and errors treated in aggregate evaluation? closed

13:11:15 [LeeF]

ISSUE-53: resolved that tuples with errors are excluded from the multiset of lists passed to aggregate functions, and that the count of such excluded errors is passed to the aggregate function, no abstentions or objections

13:11:15 [trackbot]

ISSUE-53 How are unbounds and errors treated in aggregate evaluation? notes added

13:11:28 [LeeF]

subsubtopic: SUM

13:11:48 [LeeF]

AxelPolleres: (1) any non-numeric value in SUM is not considered

13:12:00 [LeeF]

... (2) do we allow multi-argument SUM?

13:12:07 [LeeF]

SteveH: my temptation is to sum over the tuple and then sum the sums

13:12:30 [LeeF]

LeeF: that's what I do

13:13:03 [Souri]

q+

13:13:04 [AxelPolleres]

multi-argument SUM to be defined in the straightforward way, i.e. sum arguments

kasei: re: use cases for multiargument MIN. Would an IF function address these use cases?

13:35:15 [LeeF]

SteveH: my use cases involve not knowing the type of the values involved

13:35:44 [AxelPolleres]

greg says, you can use "<" + IF?

13:36:04 [AxelPolleres]

leeF: ORDER BY is more powerful than "<"

13:36:16 [SteveH]

_:b < "foo"

13:36:51 [AndyS]

_:b < "foo" is an error : ORDER will give _:b before "foo"

13:37:00 [LeeF]

ack pgearon

13:37:42 [LeeF]

pgearon: fn:MIN(MIN(?a), MIN(?b)) - why is this not identical to MIN(?a, ?b)? because of ORDER BY semantics? errors? something else?

13:38:01 [LeeF]

AndyS: fn:min is an aggregate function in F&O - it takes one argument - a sequece

13:38:06 [LeeF]

... we don't have sequence types in SPARQL

13:41:38 [LeeF]

AxelPolleres: how would people feel about re-opening ISSUE-53 to pass errors to the aggregates?

13:41:39 [LeeF]

q?

13:41:41 [LeeF]

q+

13:41:51 [LeeF]

... COUNT would be defined to exclude thoes

13:41:56 [LeeF]

... MIN and MAX would exclude just those values

13:43:03 [LeeF]

ack me

13:43:19 [AndyS1]

AndyS1 has joined #sparql

13:43:51 [LeeF]

LeeF: My concern is more that errors and unbounds are treated the same way - unbounds in SPARQL seem so natural and innocnet that I don't see why they should have such a strong negative effect on the rest of a tuple passed to an aggregate

13:43:58 [kasei]

so this is AndyS' idea of using something other than Eval() in aggregate evaluation?

13:44:12 [LeeF]

AndyS: we would need to change aggregate eval to special case an expression that was just a variable

13:44:22 [LeeF]

SteveH: we'd also need a token for the unbound variable

13:44:53 [AxelPolleres]

-.05 on introducing NULL in SPARQL

13:45:58 [AndyS]

?x and ?x+0 (?x always a number or unbound) are then different

13:46:10 [AxelPolleres]

PROPOSED: reconsider the resolution on ISSUE-53 noting that tuples with errors passed to aggregate functions, and that the the aggregate function needs to define how tuples with errors are dealt with. COUNT excludes tuples with errors passed to the aggregate function

13:46:23 [AxelPolleres]

for whom that wouldn't work?

13:47:24 [LeeF]

I would prefer to continue as we are now rather than go with that proposal, AxelPolleres

13:47:53 [LeeF]

I'm not too happy with having to introduce an unbound token, either

13:50:20 [LeeF]

AxelPolleres: notes conensus around multiargument MIN and MAX

13:50:26 [SteveH]

SUM() will flatten the tuples, and apply ORDER BY semantics over the list

13:50:43 [LeeF]

s/SUM/MIN

13:50:48 [SteveH]

s/SUM/MIN and MAX()/

13:51:07 [AxelPolleres]

AVG, GROUP_CONCAT, and SAMPLE

13:51:08 [SteveH]

Definition: Avg

13:51:09 [SteveH]

Avg(M) = Sum(M) / Count(M)

13:51:27 [LeeF]

OK with me

13:51:59 [LeeF]

AxelPolleres: this would limit us to single argument AVG

13:52:07 [LeeF]

SteveH: potentially a reason for multiargument SUM

13:52:16 [SteveH]

implies that AVG() is single argument too

13:52:20 [LeeF]

bglimm: or an argument for all single argument aggregates!

13:52:27 [LeeF]

AndyS: what about lots of zeroes?

13:52:27 [SteveH]

need special case for |M| = 0

13:53:02 [AxelPolleres]

div by 0 is just an error, no special case needed.

13:53:12 [SteveH]

Definition: GroupConcat

13:53:12 [SteveH]

The multiset of values passed as an argument is converted to a sequence S.

AndyS: problem with the use of a keyword is we need to define the keywords... if group_concat is special, i find it odd that you can't write a custom function that could do the same thing as group_concat

14:05:28 [dcharbon2]

back to liking group_concat(",",a,b,c) - separator is req'd and is first arg

14:05:28 [sandro]

group_concat(list(a,b,c), ",")

14:05:30 [SteveH]

group_concat(a,b,c separator=",") is nicer IMHO

14:05:48 [AxelPolleres]

q?

14:06:03 [LeeF]

ack kasei

14:06:17 [AndyS]

GroupConcat(?a,?b,?c [",",true]) # true is order desc

14:06:25 [LeeF]

kasei: i like the ability of providing ordering, or at least being flexible enough to do it in custom aggregate functions

14:06:33 [AxelPolleres]

q?

14:06:53 [AxelPolleres]

GROUP_CONCAT(?x "|")

14:07:17 [AndyS]

q+

14:07:34 [AndyS]

ack AxelPolleres

14:07:34 [Zakim]

AxelPolleres, you wanted to claim that GROUP_CONCAT(?x "|") would work

14:08:11 [sandro]

(in RIF they don't need commas, much to my annoyance.)

14:08:12 [kasei]

GROUP_CONCAT[ ex:seperator "|" ; ex:order_by ?x ]( ?x ) # has issues with order by expressions, but runs with the similarity to bnode syntax.

14:08:22 [SteveH]

GROUP_CONCAT[seperator="|", order_by="desc"](?x)

14:08:40 [SteveH]

or GROUP_CONCAT["|", "desc"](?x)

14:09:06 [MattPerry]

can't you just do ORDER BY on a subquery and then GROUP_CONCAT that

14:09:16 [SteveH]

MattPerry, yeah, you can

14:09:22 [sandro]

I'm very happy with named arguments, but maybe that's because I use python.

14:09:35 [SteveH]

MattPerry, actually, no, aggregates can't preseve order

14:09:59 [LeeF]

I think the most extensible thing is square bracket swith named params that affect the behavior of a function

14:10:11 [SteveH]

LeeF, +1

14:10:12 [AxelPolleres]

GROUP_CONCAT["|" "desc"](?x)

14:10:17 [LeeF]

don't care too much where the square brackets go, mainly because I think it's somewhat hideous in all cases :)

14:10:19 [sandro]

GROUP_CONCAT(a,b,c;d,e,f) (one more option... note the semi. I don't like it as much as names.)

14:10:46 [AndyS]

q+ to speak about names

14:11:28 [AxelPolleres]

I like sandros GROUP_CONCAT(a,b,c;d,e,f) ;

14:11:39 [LeeF]

ack AndyS

14:11:39 [Zakim]

AndyS, you wanted to speak about names

14:11:44 [AxelPolleres]

q?

14:12:13 [kasei]

q+

14:12:51 [LeeF]

q+ to add propose that we not include GROUP_CONCAT in SPARQL 1.1 Query

14:13:06 [AxelPolleres]

break

14:13:11 [AndyS]

Arbitrary keywords make tokenizing hard :: select= ...

14:16:11 [sandro]

There's no need for URIs or namespacing of argument names, decentralized extensibility, because they are scoped by the function name.

14:29:05 [LeeF]

I'm not sure if it's on our agenda, but I think we ought to discuss the semantics of grouping by expressions

OPTION 2.1: we can still include GROUP_CONCAT without separator character (would still allow to solve Steve's use case with the multi-argument version and then removing the trailing separator, but without order )

14:52:21 [AxelPolleres]

OPTION 2.2: omit GROUP_CONCAT from SPARQL 1.1 Query

14:52:23 [AxelPolleres]

OPTION 2.3: GROUP_CONCAT with fixed separator

14:55:05 [AxelPolleres]

Andy, steveH discussing parsing/grammar of FuncNamed

14:55:26 [AlexPassant]

AxelPolleres: Summary of options

14:55:46 [AlexPassant]

... overall design decision

14:55:55 [AlexPassant]

... allow or not extra functional arguments

14:55:59 [AlexPassant]

... option 1 and 2

14:56:02 [AlexPassant]

... + suboptions

14:56:25 [AlexPassant]

... any objection re. we need the fonctional parameter

14:56:37 [AlexPassant]

ivan: we need it

14:56:37 [pgearon]

I object to option 2

14:56:47 [LeeF]

pgearon, why?

14:56:49 [AlexPassant]

... limites use if we dont have it

14:56:58 [LeeF]

2.2!

14:57:07 [AlexPassant]

... option 2 only if 2.2

14:57:26 [AxelPolleres]

q?

14:57:29 [LeeF]

ack kasei

14:57:30 [AlexPassant]

AxelPolleres: agreement on the suboptions ?

14:57:33 [sandro]

q?

14:57:34 [pgearon]

I agree with LeeF's use case. I also think that it's useless without being able to specify the separator

14:57:34 [LeeF]

ack LeeF

14:57:34 [Zakim]

LeeF, you wanted to add propose that we not include GROUP_CONCAT in SPARQL 1.1 Query

q+ to wonder why we wouldn't do this same thing for scalar functions if we really do this

15:09:41 [AxelPolleres]

q?

15:09:51 [dcharbon2]

q-

15:09:52 [AlexPassant]

dcharbon2: not familiar w/ python but sounds good

15:10:01 [AxelPolleres]

ack Axel

15:10:01 [Zakim]

AxelPolleres, you wanted to ask about foo=bar really different from Expressions?

15:11:32 [AlexPassant]

AxelPolleres: looks like expressions

15:11:53 [AlexPassant]

... personally not in favor of the " keywords = "

15:12:03 [AlexPassant]

... objections re. existing opsions ?

15:12:26 [ivan]

group_concat(a,b ; separator -> ",") to make it look like rif ?

15:12:52 [AlexPassant]

... LeeF objects fixed separator

15:12:59 [AlexPassant]

... sandro objects with []

15:13:01 [LeeF]

s/LeeF/LeeF and kasei/

15:13:08 [AlexPassant]

... left are: 1.2

15:13:17 [AndyS]

ivan ,What does that mean in RIF (/me behind the times)?

15:13:23 [AlexPassant]

... 1.4 + 1.5

15:13:36 [AlexPassant]

... 2.1

15:13:47 [AlexPassant]

... group concat without separator

15:14:13 [AxelPolleres]

OPTION 1.2: agg(Agg; Func) - sandro1

15:14:23 [AxelPolleres]

OPTION 2.1: we can still include GROUP_CONCAT without separator character (would still allow to solve Steve's use case with the multi-argument version and then removing the trailing separator, but without order )

15:14:48 [AlexPassant]

... 1.2 -> last option w/out objections

15:14:48 [LeeF]

q?

15:15:12 [AlexPassant]

AndyS: 1.2. is confusing

15:15:16 [AlexPassant]

... style-wise

15:15:19 [AlexPassant]

SteveH: agrees

15:15:59 [ivan]

group_concat(a,b ; separator -> ",")

15:16:15 [ivan]

group_concat(a,b ; separator = ",")

15:16:42 [ivan]

group_concat(a,b | separator -> ",")

15:16:59 [AlexPassant]

SteveH: is ; an arbitrary choice ?

15:17:02 [ivan]

group_concat(a,b | separator = ",")

15:17:15 [kasei]

group_concat(a, b, separator = ",")

15:17:32 [Souri]

';' would be confusing

15:17:32 [AlexPassant]

... asking if there's a particular reason

15:17:39 [AxelPolleres]

q?

15:17:47 [ivan]

ack SteveH

15:17:47 [Zakim]

SteveH, you wanted to ask about ; specifically

15:17:47 [AxelPolleres]

ack SteveH

15:17:50 [LeeF]

ack me

15:17:50 [Zakim]

LeeF, you wanted to wonder why we wouldn't do this same thing for scalar functions if we really do this

Lee: ... talk about Entailment issues, we have a list of issues we probably can close.

18:12:44 [AxelPolleres]

Axel: Birte suggests to not tackle entailment vs. updates for this time i.e. close ISSUE-28 and ISSUE-40

18:12:58 [LeeF]

PROPOSED: Close ISSUE-28 and ISSUE-40 by noting that our current work does not specify anything about the relationship between entailment regimes and SPARQL Update

18:13:03 [ivan]

+1

18:13:09 [bglimm]

+1

18:13:11 [sandro]

+0

18:13:14 [SteveH]

+0

18:13:14 [AndyS]

+1

18:13:16 [Souri]

Souri has joined #sparql

18:13:18 [AxelPolleres]

0

18:13:22 [AxelPolleres]

q+

18:13:26 [ericP]

~0

18:13:42 [LeeF]

RESOLVED: Close ISSUE-28 and ISSUE-40 by noting that our current work does not specify anything about the relationship between entailment regimes and SPARQL Update, sandro, steveh, axelpolleres abstraining

18:13:49 [LeeF]

s/abstraining/ab straining

18:13:58 [LeeF]

s/ab straining/abstaining

18:14:20 [sandro]

axel: There would be a solution, to say for entailment we take the scoping graph for matching, then for update we use the ...

18:14:23 [LeeF]

ISSUE-20: resolved by noting that our current work does not specify anything about the relationship between entailment regimes and SPARQL Update

Birte: applies to other entailment regimes with inconsistencies as well, all these have the same solution at the moment

18:19:16 [AxelPolleres]

... we don't enforce consistency checks, but say that if inconsistencies are checked that should be returned to the user.

18:19:32 [AxelPolleres]

... MAY in the RFC sense.

18:19:35 [Souri]

q+

18:19:40 [LeeF]

ack AxelPolleres

18:19:42 [LeeF]

ack Souri

18:20:05 [AndyS]

q+

18:20:21 [AxelPolleres]

souri: we do actually point out if we find inconsistencies in OWL (at loading)

18:20:30 [LeeF]

ack AndyS

18:20:39 [LeeF]

PROPOSED: Close ISSUE-42 noting the current text that says implementations MAY check for inconsistencies and SHOULD raise an exception if they come across an inconsistency

18:20:41 [AndyS]

ack AndyS

18:20:45 [AxelPolleres]

... we could just answer with pointing out the inconsistencies

18:20:55 [sandro]

+1

18:20:59 [AxelPolleres]

Andy: if you have loaded correct data then it is not an issue.

18:21:00 [AndyS]

+1

18:21:02 [bglimm]

+1

18:21:03 [AxelPolleres]

+1

18:21:04 [Souri]

+1

18:21:06 [LeeF]

RESOLVED: Close ISSUE-42 noting the current text that says implementations MAY check for inconsistencies and SHOULD raise an exception if they come across an inconsistency, no objections or abstentions

18:21:28 [ivan]

ISSUE-42: resolved by the current text in the document ( implementations MAY check for inconsistencies etc...)

18:21:28 [trackbot]

ISSUE-42 TF-ENT What should happen for RDFS entailment in the face of inconsistencies? notes added

18:21:44 [AxelPolleres]

subtopic: finite answer criteria

18:21:49 [ivan]

trackbot, close ISSUE-42

18:21:49 [trackbot]

ISSUE-42 TF-ENT What should happen for RDFS entailment in the face of inconsistencies? closed

18:21:51 [AxelPolleres]

Birte: current state ...

18:22:08 [AxelPolleres]

... for RDF RDFS the main issues are infinite axiomatic triples.

18:22:45 [Souri]

q+

18:22:51 [AxelPolleres]

... at the moment, we return graph vocabulary, RDF(S) vocabulary, but not those infinite rdf:_n properties unless they occur.

18:23:15 [AxelPolleres]

... RIF is more tricky, because infinity can occur through recursion over built-ins.

18:23:30 [AxelPolleres]

... strongly safe fragment of RIF Core is fine.

18:24:04 [AxelPolleres]

... sandro asked whether finiteness criterion is really useful.

18:24:06 [Souri]

q+ to ask about OWL 2 RL profile

18:24:54 [AxelPolleres]

sandro: can't see practical reasons for finiteness criterion.

18:25:16 [AxelPolleres]

... think that's only from throeretical concerns.

18:25:41 [LeeF]

ack Souri

18:25:41 [Zakim]

Souri, you wanted to ask about OWL 2 RL profile

18:25:41 [AxelPolleres]

LeeF: sandro, you think that we should not satisfy the finiteness criterion for RIF Core?

18:25:54 [LeeF]

q?

18:26:09 [AxelPolleres]

Souri: there's a separate issue for OWL2RL?

18:26:21 [AxelPolleres]

Birte: OWL2RL is fine.

18:27:00 [AxelPolleres]

Ivan: we felt in the Entailment-TF that we need the blessing of the group to drop the finiteness restriction

18:27:29 [AxelPolleres]

LeeF: extension mechanism says that we need to guarantee finiteness of answers

18:27:38 [AxelPolleres]

q+

18:27:42 [LeeF]

ack AxelPolleres

18:28:51 [sandro]

ivan: weaken finiteness restriction from MUST to SHOULD

18:29:06 [AxelPolleres]

Axel: I think we have to change the extension mechanism conditions in order to lift the restriction to finiteness.

18:29:17 [LeeF]

PROPOSED: Update the SPARQL Query BGP entailment extension mechanism to weaken the requirement on finite answers to be a suggestion

18:29:22 [kasei]

q+

18:29:28 [sandro]

+1

18:30:48 [LeeF]

ack kasei

18:31:26 [AxelPolleres]

Axel: just asking whether there is a way to stream (infinite) results

18:32:30 [AxelPolleres]

Greg: for the RDF/RDFS case what if a term, that is entailed appears in the query but not in the queried graph, but is actually entailed?

18:32:54 [AxelPolleres]

Birte: We can take the graph + query vocabulary into account

18:33:15 [AxelPolleres]

... that shouldn't be a problem.

18:33:17 [LeeF]

PROPOSED: Update the SPARQL Query BGP entailment extension mechanism to weaken the requirement on finite answers to be a suggestion

18:33:21 [ivan]

q?

18:33:29 [ivan]

+1

18:33:34 [sandro]

+1

18:33:34 [AxelPolleres]

Axel: was thinking of that for D-entailment as well... taking the query vocab into account should solve that.

18:33:49 [LeeF]

RESOLVED: Update the SPARQL Query BGP entailment extension mechanism to weaken the requirement on finite answers to be a suggestion, no objections or abstentions

18:34:03 [ivan]

s/MUST/SHOULD/ is the proposed text for Andy, probably...:-)

18:34:24 [LeeF]

ACTION: Birte to email out the text change needed to weaken the finite answer criteria in SPARQL Query

AxelPolleres: Since there are RDF stores that support datatype handline but not RDFS entailment... (1) this is not D-entailment (because that sits on top of RDFS entailment)

18:39:13 [LeeF]

... (2) what these stores do is convert literals with data types to an internal canonical form

18:39:20 [bglimm]

"1.00"^^xsd:decimal is the same value as "1.0"^^xsd:decimal, but different lexical form

18:39:24 [LeeF]

... some of these would return the lexical forms of the original graphs and others would return only the canonical forms

18:39:29 [LeeF]

... two questions

18:39:37 [LeeF]

... Q1: does this influence the destination of D-entailment?

18:39:41 [LeeF]

... Birte convinced me "no"

18:39:44 [LeeF]

... so Q1 is fine

18:40:04 [LeeF]

... Q2: Should we also define a mini-entailment regime for these RDF stores that do datatype but not RDFS entailment?

18:41:39 [AxelPolleres]

G: :s :p 1

18:42:12 [AxelPolleres]

Q: ASK { :s :p "1.000"^^xs:decimal }

18:42:52 [AxelPolleres]

according to the current SPARQL document, I understand that this would return "NO"

18:43:02 [AxelPolleres]

(on simple entailment)

18:44:12 [AxelPolleres]

sandro: I would like to support something like D^-.

18:44:34 [AxelPolleres]

Andy: I wouldn't be implementing corner cases, probably.

18:44:37 [sandro]

Sandro: I think its important the RDF stores be allowed to store only their internal form of the data values. I don't want to force people to remember all the trailing zeros and whether it's xs:int vs xs:integer.

18:44:58 [AxelPolleres]

Paul: I store as much as I can of the original structure.

18:45:01 [AxelPolleres]

q+

18:45:34 [AxelPolleres]

Paul: i internally convert a number to union of all the internal representations of that number.