W3C home > Mailing lists > Public > public-rif-wg@w3.org > November 2008

[DTB] Most editor's notes addressed

From: Axel Polleres <axel.polleres@deri.org>
Date: Wed, 12 Nov 2008 02:41:39 +0000
Message-ID: <491A4263.5050109@deri.org>
To: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

1) Replaced references to rif:text and all explanations of that datatype
with references to rdf:text.

Also added the following note:

Note that the value space and the lexical-to-value-space mapping for 
rdf:text defined here are compatible with RDF's semantics for string 
literals with named tags [RDF-SEMANTICS]. Moreover, the value space and 
the lexical-to-value-space mapping for xs:string are compatible with 
RDF's semantics for plain literals. RIF implementations MAY choose to 
interpret xs:string and its subtypes as subtypes of rdf:text following 
Section 3.1 of [RDF-TEXT], i.e., interpreting strings as texts with an 
empty language tag.

"Editor's Note: We might introduce additional shortcuts, e.g. for 
rif:text in future versions of this draft. will be resolved by adding 
the rdf:text shortcuts"

Fixed: I included the rdf:text shortcut in our allowed abreviations.

"Editor's Note: The naming convention for guard predicates, particularly 
whether third parties defining their own datatypes should be 
encouraged/discouraged to reuse the standard <tt>pred:</tt> and 
<tt>func:</tt> namespaces to define their own built-in predicates and 
functions, are still under discussion in the working group."

Fixed (and likewise for negative guards), added:

"Parties defining their own datatypes to be used in RIF exchanged rules 
may define their own guard predicates for these datatypes. Labels used 
for such additional guard predicates for datatypes not mentioned in the 
present document MAY follow the similar naming convention where 
applicable without creating ambiguities with predicate names defined in 
the present document. Particularly, upcoming W3C specifications MAY, but 
3rd party dialects MUST NOT reuse, the <tt>pred:</tt> and <tt>func:</tt> 
namespaces for such guard predicates."

"== Cast Functions and Conversion Predicates for Datatypes and 
<tt>rif:iri</tt> =="

renamed to:

"== Datatype Conversion and Datatype Checking =="

in order to resolve:
"Editor's Note: It was noted in discussions of the working group, that 
except guard predicates, also an analogous built-in function or 
predicate to SPARQL's datatype function is needed. This however has some 
technical implications, see 

I added a new pred:hasDatatype predicate here, please check, especially 
Dave (since I didn't find your mail on that, I am not sure whether this 
was how you intedned it, but this is how it makes sense to me)!

Editor's Note: Conversion from <tt>rif:iri</tt> to <tt>xs:string</tt> 
and vice versa is still under discussion in the working group since 
<tt>rif:iri</tt> is not a datatype. For details, we refer to 
Issue-61]. The following is a strawman proposal which might still change 
in future versions of this working draft.}}

done: Renamed pred:iri-to-string to pred:iri-string

"Editor's Note: In the following, we adapt several cast functions from 
<nowiki>[</nowiki>[[#ref-xpath-functions|XPath-Functions]]]. Due to the 
subtle differences in e.g. error handling between RIF and 
<nowiki>[</nowiki>[[#ref-xpath-functions|XPath-Functions]]], these 
definitions might still need refinement in future versions of this draft."

done: removed the general remark on casts in the beginning of that 
section and added the agreed predicates.

"Editor's Note: We might split this subsection into separate subsections 
per casting function in future versions of this document, following the 
convention of having one separate subsection per funtcion/predicate in 
the rest of the document. However, it seemed convenient here to group 
the cast functions which purely rely on XML Schema datatype casting into 
one common subsection."

done: I split it.

" Note that the subtypes of <tt>xs:integer</tt> do appear in the 
conversion table in 
Section 17.1] of 
Conversions from and to subtypes of <tt>xs:integer</tt> follow the same 
considerations as <tt>xs:integer</tt> in that table, by the XPath, 
XQuery type hierarchy in 
Section 1.6] of 

I removed that, we aren't talking anymore about the subtypes of 
xs:integer in the document.

"Editor's Note: The cast from <tt>rif:text</tt> to <tt>xs:string</tt> is 
still under discussion, i.e. whether the lang tag should be included 
when casting to <tt>xs:string</tt> or not."

Casting to xs:string:

I changed the indented domain from:

"The union of the value space of <tt>rdf:text</tt> with the value spaces 
of datatypes castable to <tt>xs:string</tt> according to 
Section 17.1] of 

to just:

"The value spaces of datatypes castable to <tt>xs:string</tt> according 
Section 17.1] of 

For conversion/extraction from rdf:text, the extraction functions shall 
be used.... note: string-casts from rdf:text are thus no longer possible 

10) I removed the rdf:text cast function.

Will work on the remaining 6 Editor's notes shortly.


Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
email: axel.polleres@deri.org  url: http://www.polleres.net/
Received on Wednesday, 12 November 2008 02:42:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:53 UTC