Re: [RIF-XMLdata] Updated draft (reply to Gary)

Hi Gary,

Gary Hallmark wrote on 14/09/2009 21:14:18:
> 
> Here's my review, which complements Dave's, I think.

Thank for the comments. I think that they are completely in line with 
Dave's, indeed.

> Overall, I am bothered by the difference in style as compared to SWC. 
> Both attempt to define the semantics of combinations. SWC does so by 
> embedding RDF/OWL in RIF.

That is not my understanding: SWC does not specify the combination of RIF 
and RDF/OWL by embedding them. But it specifies, indeed, a (non-normative) 
embedding in the appendix, which can be easily done for the combination of 
RIF with XML data as well (for a future draft).

And, anyway, I do not see the benefit of trying to emulate SWC: Combining 
RIF with RDF/OWL is a completely different problem from combining it with 
XML data. One is essentially a problem of semantics, the other one is 
mostly a problem of syntax.

And the target audiences are different, too :-)

> XMLdata, on the other hand, attempts to 
> introduce some notions into RIF such as static and dynamic expression 
> evaluation contexts, nodes and node sequences, available document, 
> available collection, and so forth, into RIF. This causes several 
problems:
> 1. the procedural xpath/xquery semantics doesn't work when combined with 

> the model theory of BLD/Core
> 2. it forces the reader to try to comprehend both RIF and xpath/xquery 
> concepts
> I think it would be clearer to simply define how an xml document, 
> optionally with a schema, is to be mapped to frame, membership, 
> subclass, etc. formulas. Then the semantics of the combination is given 
> by RIF, and one does not have to understand the semantics of 
> xpath/xquery, only the mapping to RIF and the RIF semantics.

The draft does not use the semantics of XPath/XQuery: it relies on the 
same data model, so that we do not have to redefine one specifically to 
our purpose. But the semantics of the combination is given by RIF.

But I agree that it adds some overhead that we could do without.

The reference to XPath/XQuery is by no mean necessary: now that I 
understand better what I am trying to do, I could probably do it in terms 
of the infosets, directly. But it would just be redefining the same 
notions that we use in XDM. And I thought that it was nice to be able to 
relate RIF to XPath and XQuery.

What I propose is to specify the notions that we need independently of 
XDM, and point out that the definitions are copied from XDM, or similar to 
definitions in XDM, without refering to XDM more than that. Would that be 
better?

Regarding the notions of context, see my reply to Dave similar comment: 
would my proposal work with you? 

> I support the notion of a dynamic context if it gives us the ability to 
> support a get-current-date() builtin. 

More about that later. I have to think about it.

> I do not believe "dynamically imported datasources" are well-enough 
> specified to be interoperable. E.g. in example 3.2 there is not enough 
> information to automatically and unambiguously convert the customer 
> table to an xml document. Where did the xml:lang tags come from? Not the 

> database. What if the database has FIRSTNAME and LASTNAME columns? How 
> are they to be marshalled into the Name element?

In 3.2, the data source is imported statically... Which, by the way, 
proves your point that these notions of statically VS dynamically imported 
data sources are confusing :-)

How a non-XML data source is serialized into XML according to the provided 
schema is out of the scope of the spec. As suggested by Dave, I will 
remove that level of indirection from the example, anyway.

Re the xml:lang attribute, it is mere oversight: I just forgot to update 
the table after I added it in the XML.

> The notion of sequence is fundamental to XDM. These are ordered and 
> flat. Sometimes we may want to map them to frame slots (but then order 
> is lost), other times we may want to map then to Lists (but Lists aren't 

> flat). I would like to see some way to control the mapping, for cases 
> when order matters.

I was thinking of adding a third syntax for slot names to retrieve the 
slot sequence as a whole, instead of item by item.

Something like: if the slot name looks like "URI#All(NAME)", the 
slot-sequence is the same as if the local name was just NAME, but the 
frame:
?x[URI#All(NAME)->?y] is true iff ?y is a rif:list that is equal to the 
slot-sequence (thus preserving document order).

Should we add that? I think that Dave asked for something similar, in his 
comments on the previous version.

> Also, for some use cases, it may be desirable to 
> embed simple xml documents as nested positional terms, e.g. 
> Customer(name("john") account(111))

You mean, to allow the reference to the Customer to be anonymous?

Why not? Shall we table this as a possibility for the next version?

> In example 3.2 it seems that rules can act upon the xml document to set 
> John's ID to 111. That seems too strong, especially for Core/BLD. I 
> think the entailment holds, but I don't think entailment necessarily 
> generates new XML nodes. Probably we need some PRD-specific action 
> (export-xml or something?) for this.

The text specifically states that, for the purpose of the spec, updates of 
the available default collection are not reflected in the statically 
imported data sources.

But if we get rid of the notions of static and dynamic contexts etc, the 
problem disappear, anyway.

> Why overload Import profile by allowing it to contain a schema location? 

> Why not have 2 profiles: xml-data and xml-schema-data, where the second 
> takes an additional 2 locations, one for the data document, and one for 
> the schema document?

I do not understand: what is the benefit of *not* using the existing 
construct, since we use it exactly for the purpose it what created to 
fulfil?

The profile, in SWC, is an URI that gives the consumer the additional 
information that is needed to combine the data source identified in the 
location. It is exactly the same in my draft, except that we give 
semantics to additional values for the profile, because the additional 
information that is needed to combine RIF with XML data is different from 
the additional information that is needed to combine it with RDF or OWL.

> Can a schema-less xml document convey type information, e.g. <Account 
> xsi:type="xs:integer">111</Account>?

Shall we table that for the next version?

> In 4.1, XDM-Name is defined as a mapping from rif:iri Consts, but the 
> next to last bullet shows a mapping from an xs:string Const.

The text actually defines the XDM-Name of anything that can be casted into 
a rif:iri, by extension of the XDM-Name of rif:iris. But it seems that I 
will remove that. See my reply to Dave.

Cheers,

Christian

ILOG, an IBM Company
9 rue de Verdun
94253 - Gentilly cedex - FRANCE
Tel. +33 1 49 08 35 00
Fax +33 1 49 08 35 10



Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400 
Courbevoie
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 609.751.783,30 ?
SIREN/SIRET : 552 118 465 02430