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

Boris Motik wrote:
> Hello,
> 
>> -----Original Message-----
>> From: public-rdf-text-request@w3.org [mailto:public-rdf-text-request@w3.org]
>> On Behalf Of Axel Polleres
>> Sent: 06 April 2009 16:03
>> 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:
>>> 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
>>
> 
> Fine by me.

I implemented this now, so we need to register that ns.

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

Not sure now... there were some discussions still on the lowercase 
issue... how shall we proceed here?

>> 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.
>>
> 
> At least we should make sure that we accept both types of values; then we can
> leave the "better" solution for later.

did that - for both compare and length, renamed fn:text-compare and 
fn:text-length to rdftfn:compare and rdftfn:length, respectively, using 
the new namespace.

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

I didn't yet drop it, wasn't really resolved, but I am not against it.
maybe though, we should then drop both length AND compare... I don't see 
much sense in keeping one and dropping the other. However, I personally 
view neither of the two harmful.

Axel

> Regards,
> 
> 	Boris
> 
>> 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/
> 
> 
> 


-- 
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 22:55:18 UTC