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

ISSUE-93 (Datatype IRIs): Should datatype IRIs map to the datatypes themselves [BLD]

From: Rule Interchange Format Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Tue, 17 Feb 2009 10:30:53 -0500 (EST)
To: public-rif-wg@w3.org
Message-Id: <20090217153053.47B3D4DD65@crusher.w3.org>

ISSUE-93 (Datatype IRIs): Should datatype IRIs map to the datatypes themselves [BLD]

http://www.w3.org/2005/rules/wg/track/issues/93

Raised by: Christopher Welty
On product: BLD

During the addition of the "general guards", Jos observed that a rif:iri constant should denote an actual datatype, so one can speak about actual datatypes when speaking about the types of literals.

He suggested:

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 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.

See the thread starting here: http://lists.w3.org/Archives/Public/public-rif-wg/2009Feb/0004.html


[1] http://www.w3.org/2005/rules/wiki/BLD#Semantic_Structures
Received on Tuesday, 17 February 2009 15:31:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:03 GMT