[DTB] summary of editorial issues (completes ACTION-552)

here goes a summary of all editor's notes in DTB along with some 
proposals how they shall be addressed:

This completes ACTION-552

1) Editor's Note: rif:text (in particular, its identifying IRI) is an AT 
RISK feature. We expect a joint effort with the OWL WG to discuss 
rif:text and the equivalent OWL datatype, striving for a uniform symbol 
space for such text strings with a language tag.

should be solved by rdf:text, adapted version will be available at
by next RIF telecon.

2) Editor's Note: We might introduce additional shortcuts, e.g. for 
rif:text in future versions of this draft.

the rdf:text datatype will include the shortcut

'"' UNICODESTRING '"@' langtag

as a shortcut for:

'"' UNICODESTRING@langtag '"^^rdf:text'

and both



'"' UNICODESTRING '"^^xs:string'

will actually be shortcuts for

'"' UNICODESTRING '@"^^rdf:text'

since xs:string is planned to be a subtype of rdf:textfor rdf:texts with 
an empty language tag.

3) In the course of the rdf:text discussions, we discussed that a 
function/predicate for implementing language-pattern matching according 
to subtag matching according to RFC4647 is needed. (This is not yet 
reflected by an editor's not in the current draft.) I propose
to add:

pred:matches-langtag( ?arg1 , ?arg2 )

  intended domains:
    - arg1 rdf:text
    - arg2 valid language range according to

4) 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 pred: and func: 
namespaces to define their own built-in predicates and functions, are 
still under discussion in the working group.

PROPOSED:  Leave the naming convention as is.

5) 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 

PROPOSED: We could  - analogous to  pred:iri-to-string, define predicates

  pred:matches-datatype( ?arg1 ?arg2)

such that the predicate is true iff ?arg1 is in the value space of
the datatype denoted by ?arg2 . An open question is whether we should 
use the rif:iri or the string representing the datatypeIRI for the 
second argument, i.e. what is the intended domain for ?arg2 ??

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

PROPOSED:  Leave the naming convention as is.

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

Indeed I need to check back Jos exact concerns here, he thought that 
referring to the [XPath-Functions] conversions is not precise enough 
here, see also 8)

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

I can separate them, if the majority of theworking group thinks this is 

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

PROPOSED. replace rif:text by rdf:text, otherwise leave as is.

10) Editor's Note: Conversion from rif:iri to xs:string and vice versa 
is still under discussion in the working group since rif:iri 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.

PROPOSED: That was discussed extensively, the former section 4.3.5 
removed, so I think we can consider this done and just remove the note.

11) Editor's Note: The following treatment of built-ins which may have 
multiple arities is a strawman proposal currently under discussion in 
the working group.

PROPOSED: remove this note and stick with the shorthand introduced in 
the beginning of section 4.5 for multi-arity functions and preds.

12) Editor's Note: The working group is currently discussing, whether in 
addition to adopting the fn:compare function from [XPath-Functions], own 
predicates pred:string-equal, pred:string-less-than, 
pred:string-greater-than, pred:string-not-equal, 
pred:string-less-than-or-equal, pred:string-greater-than-or-equal not 
defined in [XPath-Functions] shall be introduced, following the 
convention of having such predicates for other datatypes.

PROPOSED: introduce additional comparison predicates.

13) Editor's Note: No less-than-or-equal or greater-than-or-equal 
predicates are defined in this draft for durations, since there are no 
separate op:dayTimeDuration-equal nor 
op:yearMonthDuration-equalpredicates in [XPath-Functions], but only a 
common predicate op:duration-equal. Future versions of this working 
draft may resolve this by introducing new equality predicates 
pred:dayTimeDuration-equal and pred:yearMonthDuration-equal with 
restricted intended domains.

PROPOSED: introduce a single predicate duration-equal that only 
evaluates to true if the arguments are both of the same duration subtype 
and equal.

14) Editor's Note: Predicates for rdf:XMLLiteral such as at least 
comparison predicates (equals, not-equals) are still under discussion in 
the working group.

PROPOSED: introduce equals and not-equals for XMLLiteral which matches 
modulo white-spaces in non-text content.

15) Editor's Note: The current name of this function is still under 
disscussion in the working group. Alternative proposals include e.g. 
func:lang-from-text, which follows the XPath/XQuery naming convention 
for extraction functions from datatypes than the SPARQL naming convention.

PROPOSED: change to func:lang-from-text and only add a remark that this 
is related to SPARQL's lang-function.

16) Editor's Note: We have not yet included comparison predicates 
(equal, less-than, greater-than, or compare ...) for rif:text. Future 
versions of this document might introduce these.

PROPOSED: only add equal and not-equal for rdf:text, for more 
sophisticated comparisons conversions to strings and the more 
fine-grained comparisons on  strings can be used.

Dr. Axel Polleres, Digital Enterprise Research Institute (DERI)
email: axel.polleres@deri.org  url: http://www.polleres.net/

Everything is possible:
rdfs:subClassOf rdfs:subPropertyOf rdfs:Resource.
rdfs:subClassOf rdfs:subPropertyOf rdfs:subPropertyOf.
rdf:type rdfs:subPropertyOf rdfs:subClassOf.
rdfs:subClassOf rdf:type owl:SymmetricProperty.

Received on Monday, 18 August 2008 16:12:36 UTC