Re: Processes as instances: Some suggestions

Hi Monika -

I agree with what you are suggesting, in general - that we have a set of 
classes for describing IOPE's, which are used both in profile and 
process.   I have two comments:

1) From the beginning, we've always regarded IOPE's as "belonging to" 
the process model, more so than the profile - and I think that's the 
most clear way of thinking about them.  So if we adopt the approach 
you've outlined, I would strongly favor moving InputDescription, 
OutputDescription, etc. from Profile.daml to Process.daml.  (Of course 
then they could be referenced from Profile.daml.)

2) Marta has made a renaming suggestion that we should consider.  Instead of
   input ranges over InputDescription
   output ranges over OutputDescription
etc.

why not use
   hasInput ranges over Input
   hasOutput ranges over Output
etc.

(Here again I would have the classes Input, Output, etc. declared in 
Process.daml.)

Best regards,
David

Monika Solanki wrote:

> 
> Hi All :
> 
> I tend to agree with Massimo. Further to that I have a few suggestions ( 
> It may have been mentoined earlier, I am not sure) . I am reproducing 
> here part of David's example from CongoProcess.
> 
> <process:AtomicProcess rdf:ID="ExpressCongoBuy">
>  <process:input>
>    <process:IOSpec rdf:ID="congoBuyBookISBN">
>      <process:IOName rdf:resource="congoBuyBookISBN"/>
>    <!--DLM: IOType, inputType, or daml:type? -->
>      <process:IOType rdf:resource="&xsd;#string"/>
>    </process:IOSpec>
>  </process:input>
> </process:AtomicProcess>
> 
> As we see here, David has introduced IOSpec for defining properties of 
> the input like "Name" and "Type" and we would need similar things for 
> specifying all the other properties. Now with the latest developments 
> with the correspondence between these properties in Profile and Process, 
> we have well defined classes "InputDescription" etc which offer the 
> properties like functionalPropertyName <--->IOName as above , restricted 
> To <----->IOType as above. Can we use these classes for specifying the 
> Functional properties in the Process model ?. This way we can ensure 
> that the description of the properties stay in one place and only 
> references are made wherever the mapping needs to be defined. So if  we 
> define "InputDescription" in Profile, in Process we can write:
> 
> <daml:Property rdf:ID="input">
>  <rdfs:subPropertyOf rdf:resource="#parameter" />
>  <daml:range rdf:resource="&profile;#InputDescription" />
> </daml:Property>
> 
> I hope I am not violating any rules here (circular reasoning???). But 
> seems like this will make the binding a bit more tight between the 
> profile and process models. I may be completely wrong with this.
> 
> Thanks,
> 
> Monika
> 
> Massimo Paolucci wrote:
> 
>> Martha, David and all,
>>
>> I did not look at the issue of the relation between the process and
>> the profile under the PAI model,  as I am trying to sort out the other
>> issues first (trace and data flow).  Nevertheless,  I do not
>> understand why we cannot do the same thing that we do in the PAC
>> case.  Most likely the owl representation will have to be modified to
>> account for references to instances instead of classes, but the
>> underlying model should still be the same...or may be I am missing
>> something important.
>>
>> --- Massimo
>>
>> -- 
>> [To unsubscribe to this list send an email to "majdart@bbn.com"
>> with the following text in the BODY of the message "unsubscribe 
>> daml-process"]
>>
>>  
>>
> 
>

Received on Monday, 18 August 2003 00:46:52 UTC