Re: I made an editorial pass over Section 5 of the document

Boris Motik wrote:
> Hello,
> 
> I don't think we need two functions; after all, extended ranges cover the basic
> ones. Hence, if we have a function for the extended matching, we immediately
> have the one for basic matching. Hence, the best way to go might be to just
> support extended matching in the functions. My main point was that we should
> make this clear.

I adopted this (extended language range matching) and removed the Ed note.

The only editor's notes remaining are:

1) Editor's Note: Reuse of the fn: namespace in the following functions 
is still under discussion, cf. 
http://lists.w3.org/Archives/Public/public-rdf-text/2008OctDec/0020.html

PROPOSED: I suggest to define our own namespace
rdftfn: http://www.w3.org/2009/rdftext-functions

2)
Editor's Note: RDF requires language tags to be in lowercase. To 
minimize the discrepancy with RDF, the lexical forms of rdf:text also 
require language tags to be in lowercase. This function should be more 
explicit about how it handles the case. There two possibilities: either 
it requires the language tag argument to be in lowercase (and raises an 
error if it is not), or it simply converts $arg2 to lowercase. At the 
moment, the latter option was chosen.

PROPOSED: I suggest to simply drop this if there are no strong 
objections to this solution.

3) there are some Ed notes left in
Section 5.2.1 and 5.3.1


* in Section 5.2.1

{{EdNote|[[User:Bmotik2|Boris Motik]] 27 march 2009| This function 
should be modified such that it accepts both values with a language tag 
as well as values without it.<br /><br /> There is, however, an 
alternative way of handling this. Since xs:string values are now 
rdf:text data values, would it be possible to simply extend the 
fn:compare function from XQuery? That is, the definition of fn:compare 
would be extended such that it accepts all four combinations of 
arguments. This would be quite beneficial to the users, as they would 
not need to fiddle with different functions.}}

As said, I agree with the latter, but it will need to get back to the 
XQuery/XPath group. In doubt and to get to a conclusion, I am also fine 
to drop this function, since it can be emulated by the extractors and 
fn:compare.

* As for text-length,

{{EdNote|[[User:AxelPolleres|AxelPolleres]] 12 November 2008 
(UTC)|'''Open Issues''': The inclusion of text-length, as well as the 
definition of the function - whether the length of an rdf:text value 
should concern only the string part - are still under discussion.}}

As mentioned already, the easiest solution seems to be to indeed drop 
it. We can emulate the respective facets in RIF still by extraction and 
respective string functions.



That would be it?

Axel

> Regards,
> 
> 	Boris
> 
>> -----Original Message-----
>> From: Axel Polleres [mailto:axel.polleres@deri.org]
>> Sent: 06 April 2009 15:26
>> To: Boris Motik
>> Cc: public-rdf-text@w3.org
>> Subject: Re: I made an editorial pass over Section 5 of the document
>>
>> Boris Motik wrote:
>>>>> - It is not clear whether the function allows for basic or extended
>> language
>>>> tag
>>>>> matching.
>>>> My personal feeling is that basic language tag matching is pretty
>>>> pointless. So, I suggest we support extended matching.
>>>>
>>> I'm fine either way; my comment was that we should just be explicit about
>> what
>>> we mean.
>> The easiest solution seems to add an additional
>>
>>   fn:matches-language-range-basic
>>
>> That does only basic lang-range-matching, but wait, wouldn't that be
>> superfluous anyways... isnt't basic lang matching just
>>
>> $range = "*" =boils down to=> fn:lang-from-text($arg is not empty
>>
>> and otherwise just
>>
>> $range = "XYZ" =boils down to=> fn:lang-from-text($arg) == "XYZ"
>>
>> ?
>>
>>
>>
>>
>>
>>> In the rdf:langRange facet, however, I strongly advocate going with the
>> basic
>>> matching. Note that, in OWL, we need to solve existential constraints over
>>> facets, and it is not clear to me how to implement this with extended
>> matching.
>>>> BTW: Here, we still refeer to BCP-47. Is that ok ,or given the latest
>>>> changes, it would be advisable to refer to the fixed spec RFC 4647 instead?
>>>>
>>> I don't really know what the conventions regarding that are.
>>>
>>> Regards,
>>>
>>> 	Boris
>>>
>>>> Axel
>>>>
>>>>> I've added two new EdNotes explaining that. Please let me know should you
>>>> find
>>>>> any problems any of my changes.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> 	Boris
>>>>>
>>>>>
>>>> --
>>>> Dr. Axel Polleres
>>>> Digital Enterprise Research Institute, National University of Ireland,
>>>> Galway
>>>> email: axel.polleres@deri.org  url: http://www.polleres.net/
>>
>> --
>> Dr. Axel Polleres
>> Digital Enterprise Research Institute, National University of Ireland,
>> Galway
>> email: axel.polleres@deri.org  url: http://www.polleres.net/
> 


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/

Received on Monday, 6 April 2009 15:03:35 UTC