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

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