Re: [TED] Worked Examples of Use Cases Updated According to RIF Core WD1

Adrian Giurca wrote:
> 
> I don't understand the reasons why the final translation is a RDF 
> document. I guess some explanations are desirable. 

The context has changed enough that that worked example is now out of date.

To refresh on the original context. Many months ago I proposed [1] that 
RIF could use RDF syntax for the top level structure of rulesets, rules 
and associated metadata with the conditions and actions being expressed 
as XMLLiterals using the RIF condition/action languages.

This seemed to me to give the flexibility of RDF for metadata, the 
extensibility of RDF for adding new condition/action sublanguages while 
avoiding all the logical mess that arises from the lack of quoting or 
substructure in RDF.

UC8 was written in that style (a) because at the time there was no top 
level ruleset syntax and (b) to explain what that style would look like.

Whilst that proposal has never got onto the agenda and so we've never 
formally discussed it I take Gary's comments to mean that this approach 
would be unacceptable to him and so presumably the proposal is dead. In 
which case the use case as written is no longer relevant to the current 
direction of RIF.

I assume Harold was just updating the conditional language part to be 
compatible with the current proposal but in fact the whole example would 
need to be rewritten from scratch. That can't be done until we have:
   - an abstract syntax for sorts
   - an abstract syntax for the slotted notation
   - a mapping of that slotted notation into RDF
   - an abstract->XML syntax mapping
   - agreement on the metadata representation
   - agreement on the minimal builtin predicates

> Indeed JenaRules use 
> RDF(S) as a vocabulary language. Is this the intention of RIF?

?? The top level rule syntax is a completely different thing from a 
vocabulary language. Do you really mean vocabulary language there?

That use case concerns data which is expressed in RDF, the use case 
involves writing rules which manipulate that data. It is certainly the 
intent that RIF be able to manipulate data expressed in RDF as well as 
other data formats.

> 1. First I guess that properties like "hasNIC" or "hasIP" must be  "NIC" 
> or "IP". If they are named "hasNIC"  then this denotes a boolean 
> property which is not the case here. 

"must be"?

It is a not uncommon convention to disambiguate a relation name that 
could be read in two directions using the pattern "hasX" and "xOf", for 
example hasParent/parentOf, that is the convention being used here. Or 
rather used in the application from which the use case was abstracted.

Conversely the convention that leading upper case is reserved for class 
names is very common making your proposed alternatives unattractive.

You may not like either convention but I don't really think naming 
convention of predicate names in use cases is an issue we need to worry 
about just now.

>I propose the following markup for 
> rule 1 in  source rules 
> <http://www.w3.org/2005/rules/wg/wiki/UC8_Worked_Example#head-31e6e6f127874865b611fa0516c76e96fb9abcc1> 
> 
> 
> <rif:Rule rif:id="r1-computeNodeToServer">

In the original that was a label (i.e. human readable, possibly 
internationalized, language string) not the relative IRI which is "#r1".

Part of the point of that use case was to show how the metadata like 
label, comment and author could be attached to the rules.

> <rif:If>
> <rif:And>
> <!-- (?x rdf:type it:ComputeNode) -->
> <rif:Uniterm>
>  <rif:Predicate rif:id="it:ComputeNode"/>

rif:Predicate is not in the current RIF syntax that I can see.

>  <rif:Var rif:name="?x"/>
> </rif:Uniterm>

That seems to use a unary relation to represent RDF type but didn't the 
working group reject that approach in favour of slotted syntax (whatever 
that turns out to be)?

> <!-- (?x it:hasNIC ?i)  -->
> <rif:Uniterm>
>  <rif:Predicate rif:id="it:NIC"/>
>   <rif:Var rif:name="?x"/>
>   <rif:Var rif:name="?i"/>
> </rif:Uniterm>

Again that seems to be be a binary relation instead of slotted syntax.

[snip]

> 3. In rule R3 discussing blanc nodes I don't see why the rule is not 
> written as:
> 
> [r3-applicationHost:
>     (?a rdf:type bp:Application)     (?a bp:discoveredAtIP ?p)
>     (?n rdf:type t:Server)
>    ->
>     (?n t:address ?p)  (?n t:hosts ?a)]
> 
> Why we need the blank node here?

Because there is no t:Server that will match here, your alternative rule 
could never fire. The point of the rule is that it has to do object 
introduction, in the case of RDF then a convenient way to do object 
introduction is to use a blank node.

I deliberately kept this aspect of the original application when I 
developed the use case so we had a concrete example to remind us that we 
have to decide how to handle bNodes.

>  4. About built-ins:
> In rule r4-discount I guess that, according with Jena Rules syntax , we 
> have product(?c, '0.75', ?cd) 

No that would be a string not a float literal.

> or  product(?c, '0.75'^^xs:float, ?cd). 

Yes, that would be equivalent to the original form in the use case.

> In 
> the second case the markup may be:
> 
>  <rif:Uniterm>
> <!-- if we allow RIF built-ins -->
>  <rif:Predicate rif:id="rif:product"/>
>   <rif:Var rif:name="?c"/>
>   <rif:Const rif:type="xs:float">0.75</rif:Const>
>   <rif:Var rif:name="?cd"/>
> </rif:Uniterm>

I guess this just depends whether our builtins are packaged as builtin 
predicates or builtin functions. Since we haven't yet started discussing 
builtins it's a bit hard to argue what they should look like in a use 
case example.

> 5. the triple (?a ?P ?subApp)  may be represented as:
> 
>  <rif:Uniterm>
>   <rif:Var rif:name="?P"/>
>   <rif:Var rif:name="?a"/>
>   <rif:Var rif:name="?subApp"/>
> </rif:Uniterm>
> 
> while (?P rdfs:subPropertyOf bp:comprises) may be:
> 
>  <rif:Uniterm>
>  <rif:Predicate rif:id="rdfs:subPropertyOf"/>
>   <rif:Var rif:name="?P"/>
>   <rif:Predicate rif:id="bp:comprises"/>
> </rif:Uniterm>

Given that we haven't yet agreed what the stripe-skipping rules, if any, 
are then it is hard to say if these are allowed syntactically or not. 
You mostly seem to be dropping Harold's "<op>..</op>" stripes.

I'm currently unclear whether our resolution on "overlapping sorts" 
means that Hilog-style quantification over predicate symbols is now 
allowed. In any case none of this is very relevant since we seem to have 
provisionally agreed that RDF will use the slotted syntax so all of this 
will look completely different by the time we've finished.

Dave

[1] http://lists.w3.org/Archives/Public/public-rif-wg/2006Sep/0077.html
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Tuesday, 22 May 2007 10:13:38 UTC