W3C home > Mailing lists > Public > public-rif-wg@w3.org > February 2009

Re: [DTB] Action 681 completed

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Tue, 03 Feb 2009 09:44:15 +0100
Message-ID: <498803DF.10008@inf.unibz.it>
To: Axel Polleres <axel.polleres@deri.org>
CC: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

Axel Polleres wrote:
> p.s.: I also removed the now obsolete predicate hasDatatype, which was
> the "predecessor" of
>   isLiteralOfType
> and
>   isLiteralNotOfType
> and added the respective examples and Editor's notes now under
> isLiteralOfType.
> Two more questions open:
> 1)  I thought whether we also need:
>    IsLiteral, IsNotLiteral
>  While the former can be  easily emulated by: idLiteralOfType (l ?X ),
> just leaving the variable free, especially the latter might be useful?
> Opinions?

IsNotLiteral(?x) or isLiteralNotOfType(?x, int)

is equivalent to


And so, we would bring disjunction back into the language if we were to
include IsNotLiteral.


> 2) Naming convention... I know we had agreed on isLiteralOfType and
> isLiteralNotOfType in the teleconf., but now, in the light of drafting
> literal-equal and literal-not-equal
> I ask myself which naming convention to stick to:
>  CamelCase or dash-separated ?
> best,
> Axel
> Jos de Bruijn wrote:
>> <snip/>
>>>>> Note (also an editor's note in the document):
>>>>>  I assumed the second argument of isLiteralOfType to be a rif:iri
>>>>> at the
>>>>> moment. As we defined a datatype identifier just as a unicode string
>>>>> representing an IRI in the definition of symbol spaces, it might be
>>>>> better to restrict the domain of the second argument to strings, yes?
>>>> I disagree. A rif:iri constant can denote an actual datatype, so you
>>>> can
>>>> speak about actual datatypes when speaking about the types of literals.
>>> This is what we say so far:
>>> http://www.w3.org/2005/rules/wiki/DTB#Symbol_Spaces
>>> "The identifier of a symbol space is a sequence of Unicode characters
>>> that form an absolute IRI."
>>> It is not an IRI constant, although the current definitions of
>>> isLiteralOfType  and isLiteralNotOfType talk about IRI constants as the
>>> second argument.
>> that's fine.
>>> I am happy with either keeping it like that or changing it, just wanted
>>> to point out that there are two options.
>>>> In fact, it would have been best if in BLD semantic structures the IRIs
>>>> of datatypes are mapped to the corresponding datatypes, e.g.,
>>>> xsd:string
>>>> is mapped to the XML schema string datatype.  One could then, in DTB,
>>>> speak only about values and datatypes, which will be much more
>>>> convenient and much more elegant.
>>> I am not sure what you want to say here, can you explain/maybe
>>> illustrate with an example?
>> I propose to extend the definition of semantic structure [1] by adding
>> the following conditions to point 1 of the definition:
>> - If a constant c \in Const is an IRI constant "d"^^rif:iri and d is a
>> datatype identifier, i.e., d \in DTS, then I_C(d) is the datatype [2]
>> identified by d.
>> Thinking again about this, we might get away with this change without
>> redoing last call.  The only real implication it has is that equality
>> statements of the form
>> xsd:integer=xsd:string
>> are currently not inconsistent, but with the proposed change they do
>> become inconsistent.
>> But we anyway don't want people to write this kind of statement; in
>> fact, people should not use datatype identifiers outside of constants
>> and isLiteralOfType/isLiteralNotOfType statements.
>> Best, Jos
>> [1] http://www.w3.org/2005/rules/wiki/BLD#Semantic_Structures
>>> Thanks,
>>> Axel
>>>> We should not have moved BLD to last call before finalizing DTB :-(
>>>> I now think we should probably redo BLD last call, after finalizing
>>>> DTB.
>>>>> Moreover, I think by dropping the specific guard predicates, we can
>>>>> get
>>>>> rid of the definition of short names for symbol spaces as well.
>>>> Yes.
>>>> Best, Jos
>>>>> Axel


Jos de Bruijn,        http://www.debruijn.net/
Many would be cowards if they had courage
  - Thomas Fuller
Received on Tuesday, 3 February 2009 08:45:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:07:53 UTC