- From: Sandro Hawke <sandro@w3.org>
- Date: Fri, 10 Apr 2009 13:00:41 -0400
- To: kifer@cs.sunysb.edu
- cc: Jos de Bruijn <debruijn@inf.unibz.it>, Dave Reynolds <der@hplb.hpl.hp.com>, RIF WG Public list <public-rif-wg@w3.org>
> 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. I don't know how to begin to understand the semantics when the architecture doesn't make sense, eg having two IRI symbol spaces with different semantics. My mind just stops there. Practically speaking, if you and Jos can come to consensus on this, I can probably pass on understanding the details. If you can't (and soon), then I think you guys will need to explain it to the rest of us (or at least me) in terms we can understand (eg test cases). -- Sandro > 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 17:00:50 UTC