Re: Jim Melton: XML Query WG review of RIF Datatypes and Built-Ins 1.0

Sandro,

Now, I think we're really getting somewhere!

At 10/1/2009 08:13 PM, Sandro Hawke wrote:
> >
> > One solution would be to change the name of the predicate to
> > "is-not-String", but that is not really what you're trying to
> > accomplish (I think), besides which it violates the pattern chosen
> > for the names of predicate of this category.  The other solution
> > would be to clarify that, at least for the negative guards, the
> > phrase "if s1 is in the value space of one of the datatypes in DTS"
> > from the definition.  I think the latter solution is preferable (and
> > apologize for giving the impression in my previous response that it
> > was specifically the name of the predicate that I found confusing).
>
>Consider:
>
>     is-literal-not-int("hello"^^xs:int)
>
>I don't think that's well-formed, so the semantics don't apply.

If I understand you correctly, the construct "hello"^^xs:int" is, by 
definition of the language structures of RDF, SPARQL, and related 
languages, nothing in those languages.  Therefore, it's nothing that 
can be discussed within the context of those languages.  It's merely 
some random noise, from a formal viewpoint.


>Similarly, in your FFFF example, you say "let's suppose that it is [a
>literal]".  But I think the point is that it's not a literal.  As the
>term "literal" is understood here, it means exactly all the things that
>are in the value spaces of DTS.

OK, I was not 100% sure how your group viewed this question.  As I 
suggested, to the XML Query WG, it would not be a literal, because 
it's outside the space of defined values.  It's easier for you and I 
to discuss this subject now that I know your WG has the same view.


>So maybe the problem here is about the term 'literal'.  Michael
>Sperberg-McQueen mentioned he thought that term was wrong.

I think I agree with Michael ;^)


>Would better naming here be "is-datavalue-not-int"?  Or
>"is-value-of-datatype-other-than-int"?
>
>That still doesn't suggest that we're only talking about datavalues in
>DTS, but perhaps it's better.

Perhaps the answer to this question will allow my concerns to be put to rest.

What is the result (that is, true or false) of this:
   pred:is-literal-not-integer("hello"^^xs:integer)

If the answer is true, then I still have the problem, because we have 
just agreed that "hello^^xs:integer" is not a literal in your 
language (or ours).  If the answer is false, then I'm OK.  If the 
answer is "the expression will be detected as a parse error", so it 
will not be evaluated and thus no value is returned, then I am even happier.

The ideal situation, given the discussion we're having is for one of 
the following tables to apply:

               value of ?x   "3"^^xs:int   "3.1"^^xs:decimal   "hello"^^xs:int
is-integer(?x)                 true             false              false
is-literal-not-integer(?x)     false            true               false

OR:

               value of ?x   "3"^^xs:int   "3.1"^^xs:decimal   "hello"^^xs:int
is-integer(?x)                 true             false              error
is-literal-not-integer(?x)     false            true               error

The second would, IMHO, be preferable, but I don't know (yet?) 
whether it's possible for such a value (not literal) to ever be 
generated in your language.


>I expect people will use the function like this:
>
>    ?x = "3"^^int
>    ...
>    if is-literal-not-int(?x) then ...
>
>or
>
>    if is-literal-not-int(eg:some-function(?x)) then ...
>
>and I can see how "datavalue" might be a more precise word here than
>"literal".

Yeah, I see your point, but that's not actually the part that bothers 
me.  I doubt that any function in your language has the capability of 
returning an ill-formed value (e.g., "hello" typed as xs:int), and I 
know that our language does not allow that.  So using the word 
"literal" as a shorthand for "value of something that might at one 
time have been expressed as a literal" is not a semantic 
problem.  Whether it'll confuse relatively inexperienced users is a 
different question, but not where my concerns are now.

>The word "literal" is about the syntax.  At that level, in
>the first case, the argument it's not a literal, it's a variable.  In
>the second case, the argument is not a literal, it's a function-call.
>
>I guess that's why I think "literal" is okay, because of course we're
>not operating at that syntactic level.  Since it's nonsense to read it
>(ahem) literally, one should understand it to mean "value-of-literal".
>
>If there were no cost to change it, I could probably be convinced
>"is-datavalue-not-int" or "is-value-of-datatype-not-int" would better
>names; I'm not sure it's worth it at this point.  (In fact, I think we
>settled on "literal" very quickly, because we were so tired of trying to
>figure out the semantics on a function that isn't even that important.)

Yeah, I wouldn't encourage you to change the name of the function for 
this purpose.


>Anyway, have I at least understood your point?
>
>      -- Sandro (obviously speaking for myself, and not consulting the group)
>
>(I'm quite amused that our case of metonymy here is about the word
>"literal".)

Yes, I agree that this is quite amusing and not a little ironic!

Hope this helps,
    Jim

========================================================================
Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone: +1.801.942.0144
   Chair, W3C XML Query WG; XQX (etc.) editor       Fax : +1.801.942.3345
Oracle Corporation        Oracle Email: jim dot melton at oracle dot com
1930 Viscounti Drive      Standards email: jim dot melton at acm dot org
Sandy, UT 84093-1063 USA          Personal email: jim at melton dot name
========================================================================
=  Facts are facts.   But any opinions expressed are the opinions      =
=  only of myself and may or may not reflect the opinions of anybody   =
=  else with whom I may or may not have discussed the issues at hand.  =
========================================================================

Received on Friday, 2 October 2009 18:46:18 UTC