Re: how to approach Const?

Sandro Hawke wrote:
> 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.

In XML terms having to manage nodeIDs sounds potentially annoying. As I 
said before, it seems to me to be OK to have the parse tree as a tree 
and let the model construction/compilation stage apply any scoping rules 
to the symbols to identify the coreferences.

In RDF terms then I don't see there being problems with multiple 
serializations either.

There would be an issue if we were attaching open metadata to a Const 
node and expecting it to be carried across to other references to the 
same Const. If that was needed then I'd expect the RIF syntax to include 
a declaration statement where such metadata could be attached.

> 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.)

Maybe, maybe not.

I've been treating Const as a "symbolic constant" or "logical constant" 
(as you put it in your reply to Gary) with an open semantic domain. That 
makes it pretty much an alias for rdfs:Resource and you are an 
rdfs:Resource :-)

However, I guess you are right that we are treating the RDFS model of 
asn06/7 as being a model of the parse tree not a domain ontology and so 
Const is a node in the tree. In that case sure use rif:iri or rif:href 
instead. Presumably that property would be inverseFunctional.

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Monday, 16 July 2007 13:59:49 UTC