[RIF Dialect metadata - was Re: "entailment regime"?

[I think it might be useful to separate the sub-thread concerning use of 
metadata to identify RIF dialects from the sub-thread on RDF entailment 
regimes. This is the first sub-thread and thus may be of broader 
interest in RIF.]

Sandro Hawke wrote:

>>> This is for exactly the same reason I argued that RIF documents should
>>> not be labeled with a dialect identifier, unless it's just a
>>> suggestion/hint; it provides backward compatibility. 
>> I hadn't twigged that's what you were after. I think dialect metadata is 
>> at least needed as a hint ("ah this rule set is supposed to be in 
>> dialect D, I'm sure I had a D processor around here somewhere, I'll try 
>> that one first").
> 
> I don't see how that's very helpful, since you need to handle the case
> where you've never heard of D, but you have dialect E handy, and E is a
> superset of D.  So implementations need a table of the dialects they
> implement and the components implemented by each dialect.  When they get
> a document, they determine the set of components in use and search their
> table for a sufficient dialect.  That's not as easy as dispatching on
> the dialect name, but it's not too hard.  

True. Dialect metadata is not necessary but I do think it useful.

First, it seems to me RIF is going to be used quite often as part of 
some larger business process. Once a supply chain, or whatever, is 
established there is going to be repeated use of the same processing 
flows. So the rule processor being able to check the common case that 
the rules are in the dialect it had been expecting, without having to 
parse the entire rule set to perform that validation, seems useful.

Secondly, it is useful for the supplier to have a way to communicate 
their intent separately from just the pile of pieces they use. This may 
be useful for communication purposes but might also affect tool 
processing. For example a validator tool might check that the dialect 
constraints are being met, or a RIF editor might bring up a different UI 
according to the intended dialect.

> *shrug* I guess there's no
> harm in providing "D" so implementation can sometimes avoid the table
> lookup -- I just worry that we'd get a lot of lazy implementations that
> stopped there.  (Such implementation would work fine at first, so they
> could sneak by -- and we'd only discover the problem when trying to
> deploy new dialects -- suddenly we couldn't do it because of the user
> base of non-table-dispatching implementations.)

True. However, if that lowers the cost of implementation and means more 
RIF take up that could be just fine. If RIF flourishes and processors 
find they are being asked to handle forward compatibility properly then 
they will be extended to do so.

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Monday, 9 July 2007 11:03:39 UTC