RE: import functions and operators from MathML rather than XPath/XQuery? (valueTesting)

> -----Original Message-----
> From: public-rdf-dawg-request@w3.org
[mailto:public-rdf-dawg-request@w3.org] On
> Behalf Of Eric Prud'hommeaux
> Sent: June 5, 2005 11:57 PM
> To: Dan Connolly
> Cc: RDF Data Access Working Group
> Subject: Re: import functions and operators from MathML rather than
> XPath/XQuery? (valueTesting)
> 
> On Thu, Jun 02, 2005 at 09:12:08AM -0500, Dan Connolly wrote:
> >
> > We currently import our functions and operators
> > from
> >  http://www.w3.org/TR/xpath-functions/
> >
> > The normative reference on that and
> > on http://www.w3.org/TR/xquery continue to concern
> > me, w.r.t. our schedule.
> >
> > At the rules workshop, somebody pointed out to me
> > that MathML has URIs for functions an operators,
> > e.g.
> >
> >   http://www.w3.org/TR/MathML2/appendixc.html#cedef.factorial
> 
> Factorial was a funny choice, but perhaps you could use tendsTo
>   http://www.w3.org/TR/MathML2/appendixc.html#cedef.tendsto
> to describe our assymptotic approach towards Last Call.
> 
> > I don't think it has all the ones we need; regex,
> > in particular.
> >
> > But MathML2 is already a REC, and I played around with
> > it (http://www.w3.org/2001/sw/DataAccess/mathml-rules.xml )
> > and found it integrates with the Semantic Web pretty well,
> > so I have been thinking about importing our functions
> > and operators from there instead of XQuery, and I thought
> > I'd share the thought with the WG and see if it goes
> > anywhere.
> 
> One benefit to using XQuery F&O is the dream of re-using libraries to
> supply SPARQL functionality. Also, the MathML defns are more syntactic.
> Specifically, they don't have type errors, which are pretty crucial to
> our "can't say one way or the other" approach to the open world of
> datatype relationships.

I wonder if we'll see any actual reuse tho? The differences in underlying
semantics -- no sequences and no node types in SPARQL -- mean we wouldn't be
calling into those libraries with the type and/or number of parameters
they'd be set up to look for, other than the small subset of the XML Schema
atomic datatypes we currentlhy support. The advantage I think is more a
question of reusing their library "style".

> 
> I didn't see any handy join operators to help us with the graph
> patterh. To get extra geeky, I considered defining bNodes in CONSTRUCT
> patterns as compositional functions.
>   http://www.w3.org/TR/MathML2/appendixc.html#cedef.compose
> 
> From what I've considered, MathML doesn't offer us much beyond
> notation. If we want to time-out on XQuery, it seems like we could
> take a snapshot of the parts of it that we use and Recommend that.
> 
> > This might involve a charter change... er... hmm...
> > I thought there was something explicit about using XQuery
> > functions and operators in our charter, but I don't see it
> > now.
> >   http://www.w3.org/2003/12/swa/dawg-charter
> 
> I think the word "maybe" sums up our obligations pretty well:
> 
> [[
> While the data model of the query language of this protocol is
> dissimilar to that of XQuery, a non-XML concrete syntax might reuse
> syntactic elements from XQuery to aid learning time, even if XQuery is
> not chosen as the strawman.
> ]]

"to aid learning time": that to me seems to be another of the advantages of
adopting the XQuery F&O style. That and a whole slew of nicely documented
functions to call upon (ignoring the fact that you can't pass them all the
arguments or get back all the result types they say you can.)

Howard

> 
> 
> --
> -eric
> 
> office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
>                         Shonan Fujisawa Campus, Keio University,
>                         5322 Endo, Fujisawa, Kanagawa 252-8520
>                         JAPAN
>         +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
> cell:   +81.90.6533.3882
> 
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.

Received on Monday, 6 June 2005 13:25:13 UTC