how to approach Const?

Dave Reynolds <der@hplb.hpl.hp.com> writes:

> In most cases I hope Consts will be IRIs not strings in which case
> presumably they would be:
> 
>       <Const rdf:about="http://example.com/myrules#book" />
> 
> Adopting RDF/XML style does mean we can't use qname/curie notation for
> shortening IRIs. We can only use relative IRIs so the above could be:
> 
>       <Const rdf:about="#book" />
> 
> in a document with xml:base of "http://example.com/myrules".
...
> All IRI Const nodes are likely to be serialized multiple times.
> 
> I don't understand why that might be a problem. If it really is a
> problem then there are a couple of solutions which preserve RDF/XML
> compatibility.
> 
> (i) Serialize each Const once (e.g. at first occurrence) then all
> references to the same Const would use rdf:resource:
> 
>     ...
>          <Const rdf:about="#book" />
>     ...
>       <Uniterm>
>          <op rdf:resource="#book">
>          <arg rdf:parsetype="Collection">
>             <Var rif:name="Author" />
>             <Const rif:name="LeRif" />
>          </arg>
>        </Uniterm>
> 
> (ii) Serialize Consts as blank nodes with a property giving their IRI
> 
>      <Const rif:iri="#book" />
> 

There are several issues about Consts that I hope we can separate.

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.

    In NodeID terms (so this can work without URIs), we say:

       <Uniterm>
         <op ... />
         <arg rdf:parseType="Collection">
            <Const rdf:nodeID="n32"><name>book</name></Const>
         ...

    I had been thinking that on subsequent occurances one would use a
    nodeID reference on a property (syntactically like like
    rdf:resource), but I see now that wont work because
    parseType=Collection doesn't allow it, so subsequence occurances
    will have to be like this:

       <Uniterm>
         <op ... />
         <arg rdf:parseType="Collection">
            <Const rdf:nodeID="n32" />
         ...

    which should be fine, too.  (I don't like the fact that it's not
    immediately obvious whether this is a first-occurance of a Const
    with no properties or a later occurance of the same Const, but a
    program can tell.)  In my mind, the "name" property has no formal
    semantics; it's just for roundtripping.

2.  Semantic for IRIs for Consts?   (suggestion: just syntax)

    If, intead of a nodeID, we used an IRI for a Const, ... what would
    it mean, in the Semantic Web / RDF sense?   For example, here's an
    n3 rule that says that everyone I know is a geek:

    { <http://www.w3.org/People/Sandro/data#SandroHawke> foaf:knows ?x }
    =>
    { ?x rdf:type stereotypes:Geek }

    Now, that first term is an IRI for a person, me.    How would we
    translate this to RIF?

    NOT this:

      <Const rdf:about="http://www.w3.org/People/Sandro/data#SandroHawke">

    because that Const is a syntactic element, not a person.  (I am not
    a logical constant -- I am a person.)

    Instead, I *think* Consts need another property to tie them to the
    Semantic Web.   Something like:

      <Const>
         <href>http://www.w3.org/People/Sandro/data#SandroHawke</href>
      </Const>

    Alternatives to "href" include "denotation", "standsFor", "link",
    "referent".  I'd be included to consult with Pat Hayes, at least,
    before settling on a name for it.

    An alternative, to steer RIF clear of the Semantic Web, I suppose
    would be to just use "name".   But I don't think that's a great
    idea.

Okay, it turned out to be just two issues.  :-)

    -- Sandro

Received on Friday, 13 July 2007 15:37:26 UTC