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

Dave Reynolds wrote:
> 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?
I mean by vocabulary the RDFS which contains the definitions of the 
classes and properties used in the rules.
>
> 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.
This is my point of view. For me a "hasNIC" property is a boolean 
valuated one.
>
> Conversely the convention that leading upper case is reserved for 
> class names is very common making your proposed alternatives 
> unattractive.
I agree. It must be "nic".
>
> 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.
You are right. m I send an email some time ago to propose specialization 
of Const (with possible overlapping).
>
>>  <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)?
I wait for another markup example.
>
>> <!-- (?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 see what you mean. I guess this depend of the implementation of  
rdf:type. You can generate a blank  node  when you want to match (?n 
rdf:type t:Server) and there is no triple matching it.
Then you may avoid the built-in and we don't introduce the concept of 
bNodes which is not present in other rule languages.  But may be I'm wrong.
>
> 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.
I know that, I just try to list all possibilities. In the implementation 
of product you may parse that plain 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.
I agree. I want just to suggest a solution. I am in favor of predicates 
rather than functions here.
>
>> 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 don't see the advantage of <op>. But of course may be I'm wrong and 
then we need to use <op> as in:
 <rif:Uniterm>
 <op><rif:Predicate rif:id="rdfs:subPropertyOf"/></op>
  <rif:Var rif:name="?P"/>
  <rif:Predicate rif:id="bp:comprises"/>
</rif:Uniterm>
>
>
> 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
-Adrian

Received on Tuesday, 22 May 2007 10:30:31 UTC