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

<snip/>

> 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
>        http://www.rfc-editor.org/rfc/rfc4647.txt

Why would this be necessary/useful?  We already have a function for
extracting language tags.

pred:matches-langtag( ?arg1 , ?arg2 )
is the same as
func:lang(?arg1)=?arg2

<snip/>

> 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
> http://lists.w3.org/Archives/Public/public-rif-wg/2008Jul/0096.html
> 
> 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 ??

I don't really see how this could be defined in a meaningful way.  In
any case, we already have the guard predicates, so I don't see the use.

<snip/>

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

Basically, the interpretations of the functions are not completely defined.

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

I'd say: either follow the principle of having one subsection per
predicate/function (I personally don't see the use of that) or don't
follow this principle.
in the former case, you need to split up the mentioned subsection.  In
the latter case, many subsections in the document can be merged.

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

I don't remember whether we discussed this in the working group.

<snip/>

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

Why would we want to have these comparison predicates and what does it
mean for one string to be less than another?

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


Agreed.

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

Two XML literals are equal if their values (as defined in [1]) are the
same and not-equal if their values are not the same. I cannot imagine
any other meaningful definition for equality of XML literals.

[1] http://www.w3.org/TR/rdf-concepts/#section-XMLLiteral

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

Agreed.

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

Agreed.



Best, Jos

-- 
Jos de Bruijn            debruijn@inf.unibz.it
+390471016224         http://www.debruijn.net/
----------------------------------------------
No one who cannot rejoice in the discovery of
his own mistakes deserves to be called a
scholar.
  - Donald Foster