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

Dave Reynolds <der@hplb.hpl.hp.com> writes:
> [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.

I don't totally agree with you on these points, but I think the
difference will only manifest in the phrasing of whatever Arch section
talks about the dialect identification.  And I think we're not yet at
the point of stabilizing that text.

  -- Sandro

Received on Monday, 9 July 2007 13:11:44 UTC