- From: Jos de Bruijn <debruijn@inf.unibz.it>
- Date: Sun, 12 Apr 2009 13:59:35 +0200
- To: Dave Reynolds <der@hplb.hpl.hp.com>
- CC: Sandro Hawke <sandro@w3.org>, kifer@cs.sunysb.edu, RIF WG Public list <public-rif-wg@w3.org>
Dave Reynolds 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? Depends on the definition of the dialect. > > 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? No, it is completely different. The problem we faced with datatypes is that there are constants with a possibly unknown symbol space. Basically, what we said is that you cannot use a particular symbol space in constants unless you know about it. The symbol space identifier in a constant, though, is not itself a constant and is not interpreted. The symbol space identifier in a constant just helps you to interpreted the constant itself. Jos > > 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 >>> >> > > -- +43 1 58801 18470 debruijn@inf.unibz.it Jos de Bruijn, http://www.debruijn.net/ ---------------------------------------------- Many would be cowards if they had courage enough. - Thomas Fuller
Received on Sunday, 12 April 2009 12:00:21 UTC