- 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