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

I agree with all your suggestions.

Regards,

	Boris

> -----Original Message-----
> From: Axel Polleres [mailto:axel.polleres@deri.org]
> Sent: 06 April 2009 16:36
> To: Boris Motik
> Cc: public-rdf-text@w3.org
> Subject: Re: I made an editorial pass over Section 5 of the document
> 
>  > At least we should make sure that we accept both types of values;
> then > we can leave the "better" solution for later.
> 
> Reworded to reflect that, pls check.
> I still left the second part of the EdNote, which I propose to remove id
> nobody else has strong feelings about it.
> 
> Also, I suggest to change this function name to
> 
> from
>    fn:text-compare
> to
>    rdftfn:compare
> 
> Axel
> 
> 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.
> >
> >> 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.
> >
> >> 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.
> >
> >> * 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.
> >
> > 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 15:41:13 UTC