Re: the mechanism for signatures in RIF

Dave Reynolds <der@hplb.hpl.hp.com> wrote:
>
> Michael Kifer wrote:
> 
> > The idea behind sorts is not to force some standard domains on sorts, but
> > to separate their domains so that they could be treated separately. Then
> > you start the engineering part to tailor the idea to your needs. For some
> > sorts you might want concrete domains.  For some you might want domain to
> > be disjoint with something else. For others you want some partial order on
> > the domains. And so on. It is quite surprising how far this can take you.
> 
> This makes sense.
> 
> So we would like one or more sort for symbols which can be used as 
> functions, predicates and individuals and which could be separated from 
> the sorts that we have given a concrete domain (strings, ints etc).

Yes. Probably two sorts: one for uri kind of symbols and one for the local
ones (as you mentioned below).


> At F2F4 we agreed that such symbols would be designated by URIs "in the 
> style of RDF", except for purely local symbols.
> 
>  From my point of view, uniqueness of names is a different 
> characteristic from scoping (visibility of names) and authorization; so 
> I see no fundamental problem using URI references to denote all such 
> symbols (e.g. typically using using fragment identifiers for symbols 
> with local scope) and having a single sort. However, that doesn't seem 
> to be a shared point of view :-) so it seems we want at least two sorts 
> - rif:uriSymbol and rif:localSymbol.

Yes.


> In terms of domain engineering then for rif:uriSymbol we don't want to 
> link it to any specific concrete domain. We don't want to make a unique 
> name assumption, two rif:uriSymbols may denote the same domain element. 
> We don't want any other ordering or equality structure.

Yes.

> However, if I understand the earlier comments then you want the domain 
> of rif:uriSymbol to be constrained to be disjoint from the concrete 
> domains we have defined. If that is really necessary then I'm not sure 
> how to state this while permitting extensibility. In RDF/OWL then there 
> is a set of all literal values (LV, the extension of rdfs:Literal) so 
> there we could define the domain of rif:uriSymbol as a non-empty subset 
> of Resources disjoint from LV. Presumably a similar concept could be 
> defined in RIF Core for the purpose of stating this disjointness.

I offered this only as a thought. I don't actually know if it makes sense
to say that numbers (for example) cannot be identified by URIs. The only
thing that seems clear (to me) is that the domain of URIs should be
disjoint from the domain of local symbols. Maybe the domain of local
symbols should even be disjoint from everything else (contrary to what you
suggested below).

> If this disjointness constraint is required then rdf:uriSymbol doesn't 
> correspond  directly to any of the obvious concepts from RDF, OWL so we 
> do need our own URI to denote the sort.
> 
> Lexically then the WD1 description says:
> 
> "Symbols of this sort have the form "XYZ"^^rif:uri, where XYZ is a URI 
> as specified in RFC 3986."
> 
> I don't think that is quite right. I think we want XYZ to be a 
> URI-Reference (i.e. including optional fragment identifiers).

But RFC 3986 doesn't preclude fragment identifiers, e.g., http://foo#bar.
Is it not true?

> In at 
> least the XML syntax, and possibly in the linear syntax, we also want to 
> permit relative as well as absolute URI-References.

It is not clear to me whether relative URI references should be part of the
logic (and unduly complicate it) or whether they should be treated as 
syntactic sugar. 

> Turning to rif:localSymbol, if this is really needed then it would have 
> the same lack of domain assumptions as rif:uriSymbol (indeed presumably 
> it would generally have exactly the same domain).

In my view, the whole reason for local symbols is to make them completely
hidden so that they won't interfere with any other symbol. So, as I
mentioned before, I expect the domain of local symbols to be disjoint from
the rest.

> Lexically then presumably symbols of this sort would have the form 
> "XYZ"^^rif:localSymbol where XYZ is Unicode character sequence in normal 
> form C.

I think so.


	--michael  


> Dave
> 
> 
>

Received on Tuesday, 27 March 2007 12:28:01 UTC