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

Sandro, it is a semantic issue, not architectural. An alternative to External
would be rif:special, as I proposed in the message that prompted this thread
(Diatribe...). But without a device like this there is no way to maintain
extensibility of the semantics.

michael


On Fri, 10 Apr 2009 11:21:49 -0400
Sandro Hawke <sandro@w3.org> 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 Friday, 10 April 2009 16:30:34 UTC