- From: Sandro Hawke <sandro@w3.org>
- Date: Mon, 16 Jul 2007 07:39:37 -0400
- To: Gary Hallmark <gary.hallmark@oracle.com>
- Cc: public-rif-wg@w3.org
Gary Hallmark <gary.hallmark@oracle.com> writes: > > Sandro Hawke wrote: > > 1. One parse-graph node for each Const? (suggested: yes) > > > > If the same constant occurs several times in a ruleset, are the > > occurances collected in the abstract parse graph? Does the "Const" > > element represent a constant or an occurance-in-the-parse-stream of > > a constant? I had some discussion with Gary and Hassan about this, > > in Innsbruck, and I think our conclusion was the former, they should > > be collected, as in your version (i) above. > > > > > > > No, my preference is simply <Const value="someValue" type="optionalType"/> That's what I usually call a "literal data value" (and RDF just calls a "literal"). In programming languages it's usually something like 3 (an integer) 4.1 (a float) "Hello, World!" (a string) where it is usually also called a "literal". (Unfortunately, in some branches of logic, like resolution theorem provers, the term "literal" refers to possibly-negated atomic-sentences. This ambiguity is part of what has driven me to call them "literal data values" for more clarity.) My syntax strawman, following RDF/XML, is to just put those as the child content of a property, with the datatype given in the enclosing element's rdf:datatype property, like: <Person> <age rdf:datatype="&xs;int>3</age> ...etc... If we decide to not follow the RDF/XML syntax, I'd prefer a syntax like: <Person> <age><xs:int>3</xs:int></age> which seems to follow striping nicely and lets us use XML namespaces to handle the datatype name. In any case, that's somewhat different from what I think a RIF Const is. I understand a RIF Const to be what is called a "constant" in First Order Logic (eg on its wikipedia page) and I sometimes call a "symbolic constant" or "logical constant". It's a kind of atomic term that denotes something arbitrarily in the domain of discourse. I can see how one could consider literal data values to be a kind of constant, where the text "3" in the document denotes the number three in the domain of discourse, but I find it more natural to not call those Consts -- to keep them as "literal data values". In general, I think one should always use URIs as Consts, so that multiple knowledge bases can be merged, and one can use Web dereferencing to learn more. But I understand that some portion of the WG really wanted non-URI constants, so we agreed to have both. I am unclear whether a RIF "Const" covers URIs being used as symbolic constants, or only the non-URI ones. I'm waiting to read the next version of Core/Horn to see how that has come out. Maybe something like this clarifies it: class TERM subclass Var property name: xsd:string subclass Constant subclass Literal subclass TypedLiteral property datatype: Datatype property lexicalRepresentation: xs:string subclass PlainLiteral property content: xs:string property language: xs:string? subclass GlobalConstant property name: xs:anyURI subclass LocalConstant property name: xs:string subclass Uniterm property op: Const property arg: list of TERM It may well be that this kind of thing, these logical consts, don't have any place in RIF PR, and are purely in RIF Horn. I'm pretty sure they don't exist in programming languages. > I also like <Var name="someName" type="optionalType"/> although we > hastily sort of "decided" against types for variables in Innsbruck. I think it's fair for RIF PR to have variable types, even if RIF Horn doesn't. > If you want "named constants", aka "manifest constants", "static final > variables", then I suggest > <equals> > <side> > <Var name="pi"/> > </side> > <side> > <Const value="3.1416" type="xsd:double"/> > </side> > </equals> I agree with this basic notion. In the terms above, I'd say if you want to use a symbolic constant to stand for a data value, then equate a variable to literal data value. -- Sandro
Received on Monday, 16 July 2007 11:40:43 UTC