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

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/

Received on Monday, 6 April 2009 15:16:14 UTC