Re: meaning of rif:External (was Re: Diatribe on why rif:iri consts should be left alone)

On Sat, 11 Apr 2009 13:00:59 +0100
Dave Reynolds <der@hplb.hpl.hp.com> wrote:

> Jos de Bruijn wrote:
> > Sandro,
> > 
> > I was arguing about the technical details of the formal meaning of
> > symbols in the language. You are talking about good practice when using
> > IRIs. So, I'm having some trouble to relating your point to the discussion.
> 
> It is somewhat related to my point about use of namespaces to reserve 
> parts of URI space for future datatypes and thus avoid any extensibility 
> problems.
> 
> > My example was probably somewhat misleading, since BLD does not allow
> > using the same symbol as both an external predicate and an uninterpreted
> > predicate.
> 
> So if some future dialect extends the BLD+DTB combination to introduce 
> some new functions or predicates then any rule sets which use those IRIs 
> as normal uninterpreted constants become illegal in that extension. 
> Isn't that right?
> 
> In reality, good practice on IRI usage means this will not be a problem 
> and we would not regard this as meaning that extensibility is broken.

This good practice is really a bad practice. It means that a growing, but
otherwise undistinguished, subset of rif:iri's will be taken out of circulation
and prohibited from appearing in certain places. To find out which, one has to
consult an up-to-date manual that would list such exceptions. I don't like this
kind of design even a single bit.

michael



> This is rather the same extensibility problem and solution as for 
> datatypes, is it not?
> 
> Dave
> 
> > Sandro Hawke wrote:
> >>> Dave Reynolds wrote:
> >>>> Surely the extensibility argument could equally well be applied to the
> >>>> predicates and functions in DTB. Those are denoted by rif:iris and we
> >>>> are giving them a fixed interpretation, at least as externals.
> >>> It is precisely because of the extensibility issue that we require
> >>> External() to be written around external predicates and functions. If
> >>> the name, say, func:string-join is used outside External(), it is simply
> >>> an uninterpreted symbol, and DTB has nothing to say about it.
> >> This makes me suspect we have some different ideas about how the
> >> Semantic Web is supposed to work.  Let me try to state my understanding,
> >> and then return to External().  I don't actually understand how this
> >> relates to ISSUE-93, so I don't talk about that here.
> >>
> >> I think the key architectural point about IRIs is that whenever you use
> >> one, you are automatically (to some extent) subscribing to some external
> >> semantics.  They might not be written down yet, or they might be written
> >> only in natural language.  They might even change, possibly in
> >> uncontrolled, hostile ways.  When you chose to use an IRI, you have to
> >> chose carefully.  Generally you either pick one in your own namespace or
> >> you pick one in the namespace of an organization you trust to maintain
> >> both the web content and the community usage (eg W3C).
> >>
> >> The analogy to the HTML web holds here; when you make a link out of a
> >> web page you care about, you have to think carefully about where you are
> >> linking to.  What happens to your reputation, your services, and your
> >> users if that site suddenly turns into something offensive or dangerous
> >> (eg a phishing site)? 
> >>
> >> It's also not a good plan to have one IRI refer to two different things,
> >> such that you can only tell which it refers to by context.  In what you
> >> say above, what happens if someone provides documentation in metadata
> >> about a predicate that is used in both an external and a non-external
> >> context?  Which predicate does the documentaiton describe?  In my mind,
> >> it's still about both, because they're actually the same thing.  I don't
> >> see External as changing what the IRI denotes, but as signalling the
> >> consumer that it should know how to reduce the enclosed expression to a
> >> Const (for terms) or true/false (for formulas).
> >>
> >> I suspect that's not actually the meaning given to External in BLD in
> >> the LC1 draft, but in the press to get to LC, I figured we had about the
> >> same idea about how External worked and we could hammer out technical
> >> differences later when we started having test cases, implementations,
> >> etc.   
> >>
> >> With the insight of this conversation in mind, I suggest we rename
> >> External to Evaluated.  It's not clear to me that it should appear in
> >> the model theoretic semantics; it seems more like a pragmatic check for
> >> consumers, allowing them to reason more effectively and give appropriate
> >> errors when they need to.
> >>
> >> On Michael's point about Extensibility in [1], it's not the dialects
> >> that give meaning to IRIs, it's the IRI's owner (in some sort of
> >> collaboration with the rest of the world).  So any given predicate IRI
> >> or function IRI conceptually means the same thing in every RIF
> >> document, it's just that in some dialects we can assume consumers know
> >> that meaning and in others we can't.  Arbitrary use of the IRI doesn't
> >> signal an assumption that its meaning is known, but use inside
> >> External/Evaluated does.
> >>
> >>     -- Sandro
> >>
> >> [1] http://lists.w3.org/Archives/Public/public-rif-wg/2009Apr/0029.html
> >>
> > 
> 
> 
> 


-- 
    -- michael

Received on Saturday, 11 April 2009 23:23:17 UTC