- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Sat, 11 Apr 2009 13:00:59 +0100
- To: Jos de Bruijn <debruijn@inf.unibz.it>
- CC: Sandro Hawke <sandro@w3.org>, kifer@cs.sunysb.edu, RIF WG Public list <public-rif-wg@w3.org>
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 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 >> >
Received on Saturday, 11 April 2009 12:01:48 UTC