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

Hi Dave,

Dave Reynolds wrote on 14/09/2009 03:01:44:
> 
> Here's a review.  I'm just off a transatlantic flight and somewhat jet 
> lagged so apologies for any typos or incoherence ...

Thanx all the more for the detailed comments.

> ** Substantial issues
> 
> 1. The notion of updating the XML tree of the available document in the 
> dynamic environment seems flawed and should be removed. It is only 
> specified, and only specifiable, for PRD in any case. Surely rules such 
> as the rule given in example 3.2 simply entail additional frame formulae 

> (i.e. then go in working memory in PRD). The underlying document, and so 

> its node tree in the dynamic context, should not change.

The point of the schema kind of "profile", is to be able to interchange 
the data model that the rules assume for facts that are not given in RIF 
format. The point of the schema alone import (import with no data source 
location), is to be able to interchange the data model that the rules 
assumes for facts that are not imported statically, which includes, but is 
not limited to, the case of the working memory in a PR system.

In the draft, I used the dynamic context to link those latter facts to the 
interchanged rules and imported XML schema, but I agree that it raises a 
couple murky questions.

Maybe we could just say something to the effect that:
1. any fact with which the interchanged rules interact, be they from a 
statically or dynamically imported data source, from a working memory, 
whatever, if it is associated with an XML schema, is addressed, for the 
purpose of specifying the semantics of the RIF representation of the 
rules, as if it was serialised into a valid XML instance document, 
according to the associated XML schema, if any (independently of its 
internal representation in the consumer application);
2. statically imported data sources are associated with an XML schema if 
and only if that schema's URI is included as a profile in the Import 
directive;
3. any non-RIF fact that is used in interaction with the rules, at 
runtime, and that is not imported statically, is associated with an XML 
schema if and only if there is an Import directive that specifies a schema 
(as a profile) without associating it with a specific data source (that 
is, an Import without a location);
4. and that the available documents are XDM representation of all the 
facts at evaluation time.

And leave it at that? Would that work (of course, the wordin gwould need 
some work to make it precise)?

> 1.b Given this can the whole notion of static and dynamic contexts be 
> dropped?

Sure. If we use a different way to talk about the data model that is 
assumed for the internal representation of facts in the consumer app, we 
can drop the whole notion of contexts.

> 2. The notion of URIs without namespaces in the XDM-name definitions in 
> section 4.1 doesn't work as far as I can tell. In RIF a rif:iri always 
> corresponds to an absolute URI. It might sometimes be expressed relative 

> to a base URI and so require resolution but that is irrelevant here - it 

>    is still a full URI not a relative URI and so will never have an 
> empty namespace fragment.

You may very well be right. I am still not completely comfortable with 
namespaces...

The point of URIs without namespaces, in the current draft, is to address 
unqualified XML names: what is their namespace?

> 3. The notion that other datatypes like strings can be coerced into 
> rif:uris is a new one on me and doesn't seemed to be specified here. It 
> seems unnecessary and I suggest dropping it.

I introduced them because of the pred:iri-string. I am happy to drop it, 
if there is consensus that it is not needed.

> ** more minor issues
> 
> o You mention in an editor's note that importing a RDF/OWL graph will be 

> considered in a future draft. That sounds worrying. What do you mean? 
> This should removed entirely for now. I don't want to see a working 
> draft suggest there is a different way to combine RIF and RDF documents 
> and so confuse things even further.

I will remove it for now. But we will have to include it back in a later 
draft.

The point is that, if we can combine RIF with an RDF graph, on the one 
hand, and RIF with XML data, on the other hand, it would be a nice 
property if importing the RDF graph as an RDF/XML document was 
undistinguishable, in the rule syntax, from importing it otherwise.

But, even if we do not care about having the same syntax, it is necessary 
that importing an RDF graph as a RDF/XML document have the same semantics 
as importing it otherwise.

Or isn't that correct?

> o In Section 3, "Definition (Available collections)" you reference "that 

> string" without explaining what it is. Is that the URI of an imported 
> document? If so then say so.

The definition is copied from XDM: I may have missed something in the 
context (in the XDM doc).

My understanding is that the definition says that the available 
collections defines a mapping from strings onto sequences of nodes, and 
that the fn:collection function "implements" that mapping, that is, the 
result of fn:collection with string S as its argument, is the sequence of 
nodes that the available collections mapping maps S onto.

But we do not really need the reference to fn:collection. And if we make 
the spec less dependent on XDM (see my reply to Gary), we can just get rid 
of that definition (and terminology).

> o The addition of an RDB to XML schema mapping complicates the document. 

> Is it necessary? Could this document not simply focus on the XML mapping 

> and leave RDB->XML mapping to others?

The point was to illustrate that, if associated with an XML schema, the 
imported data source can be anything, not only an XML instance document.

But you are right, that added level of mapping does not bring anything 
more than that illustration. I will remove it.

> o In Example 3.2 the XML serialization of the RDB contains "en" and "fr" 

> xml:lang codes but there is no indication of where these codes come 
> from. This serialization is then used later on. I prefer to drop the RDB 

> altogether in which case this serialization becomes standalone. If you 
> keep the RDB notion then explain where the lang tags come from.

ooo^s. Oversight. I added them afterwise and I forgot to update the RDB 
:-)

But if we drop the RDB, anyway...

> o Also in Example 3.2 the first sentence following the rule example is 
> wrong. The rule does not say what you say it says. It says that Customer 

> instances will have *an* Id matching its Account number. In the case 
> where a Customer had an Account number 333 and an Id 222 the rule would 
> add Id 333 leaving it with two Ids, it would not equate 222 and 333.

Right. I will correct that.

> o In section 4.1 you could have prefixes defined in the cases where the 
> namespace URI matches a prefix binding declared in the RIF document. I 
> don't know that would have any value.

I am not sure I understand: there are no prefix binding in RIF document. I 
mean, in RIF/XML documents.

> o Example 4.6, bullet 2. I don't think this holds in the schemaless case 

> because the 111 is not an xsd:integer in that case. I don't agree with 
> the associated editor's note. How can you possibly change the definition 

> of frames to allow strings to match integers?

My point was that, in the schema-less case, we do not know whether 111 is 
intended to be a string or a number: all we have is the character data. 
So, why should we decide that it is a string rather than a number, esp. if 
the designer of the rule tells us that it should (or may) be a number?

The fact that the typed-value is a string in the schema-less case is only 
a side-effect of reusing the definition from XDM "blindly". One more 
reason to do what I propose in my reply to Gary: redefine everything we 
need without reference to XDM, and only point out the commonalities with 
XDM afterwards.

> o Example 3.6, bullet 4. The type of "en" is not xml:lang, that is not a 

> type. Perhaps you mean xs:language but in any case you might just as 
> well use xs:string.

Yes, I meant xs:language. And that could be, indeed, xs:string. Is using 
xs:language a problem (we are in an extension anyway, since a schema is 
imported)?

> o Example 4.7. The variable names don't match up. Perhaps you mean:
> ... ?v["letterBody"->?y] will be true if and only if ?y is ...

corrected.
 
> ** editorial
> [...]

I will take those into account, too. I need to check, because I made a 
number of small editorial changes and corrections, after reading the 
document, myself, on a transatlantic flight as well :-)

Thanx again for the comments.

Will you be able to attend the telecon tomorrow?

Cheers,

Christian

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