Re: Processes as instances: Some suggestions

David Martin wrote:

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

Exactly, I would also vote strongly for this. I mentoined Profile only 
as a temporary place, as the ongoing discussion for the changes has been 
with respect to that.

>
> 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 02:42:03 UTC