- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Tue, 27 Mar 2007 11:30:46 +0100
- To: Michael Kifer <kifer@cs.sunysb.edu>
- CC: RIF <public-rif-wg@w3.org>
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). 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. 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. 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. 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). In at least the XML syntax, and possibly in the linear syntax, we also want to permit relative as well as absolute URI-References. 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). Lexically then presumably symbols of this sort would have the form "XYZ"^^rif:localSymbol where XYZ is Unicode character sequence in normal form C. Dave
Received on Tuesday, 27 March 2007 10:30:58 UTC