[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs-dex] Issues with identification and classification
Tim... I sent this as a reply to another email but thought I'd copy it here. Apologies for dups. All, I think you've misunderstood my point. The real point is that the document Rob B sent was clearly trying to distinguish between Reference Data concepts (i.e. add semantic to the schema). For the use of RD in PLCS for data exchange and scenarios beyond data exchange (such as Web service access to the RD for use in applications trying to apply it) to work properly, all such meaning must be in the RDL, not in the exchange file. One approach is not more flexible than the other - remember organizations can extend the standard RD with anything they want. It's a question of where the schema-related semantics get specified. Cheers, David As a PS: I don't see the point of worrying about 200 classes that will only be used a few times in an exchange file when we're going to end up with 100K classes and classifications everywhere. There is not really any noticeable overhead to using RD in this case. PSS: I'd also suggest that the context concepts are actually often the most important concepts in an exchange file. They tell you whether anything else in the file is of interest. Therefore, these should be managed and used in a strict and rigorous manner. David -----Original Message----- From: Tim Turner [mailto:timturner11@bellsouth.net] Sent: 02 February 2005 15:04 To: Trine.Hansen@dnv.com; rob.bodington@eurostep.com; timturner11@bellsouth.net; david.price@eurostep.com; plcs-dex@lists.oasis-open.org Cc: orjan.falk@eurostep.com; jonas.rosen@eurostep.com; Leif.Tonning@dnv.com; magnus.farneland@eurostep.com Subject: RE: [plcs-dex] Issues with identification and classification I also prefer the explicit (& consistent) route described - I concur. What about others (pilot people)? Tim -----Original Message----- From: Trine.Hansen@dnv.com [mailto:Trine.Hansen@dnv.com] Sent: 02 February 2005 09:07 To: rob.bodington@eurostep.com; timturner11@bellsouth.net; david.price@eurostep.com; plcs-dex@lists.oasis-open.org Cc: orjan.falk@eurostep.com; jonas.rosen@eurostep.com; Leif.Tonning@dnv.com; magnus.farneland@eurostep.com Subject: RE: [plcs-dex] Issues with identification and classification All. We seem to have three different issues here. One relates to classification when an entity has two different attributes that needs classification (e.g. view_definition_context.life_cycle_stage/application_domain). The other relates to classification when an attribute may hold different types of data (e.g. multiple instances of identification_assignment.identifier may have roles of name or of code). The third relates to which data should be classified in the external RDL in order to satisfy different implementation options, i.e. integrate DEX and RDL in a translator in scenarios like * an Express and PLCS based implementation that translates the entire -239 data model, * an application that only browses the data for presentation purposes, * an implementation that relies on interactive use of the external RDL, * an implementation that does not have an interactive connection to the RDL, * changes in the PLCS RDL population that are not yet implemented by all translators. To the first issue: Our preferred solution has been to use attribute classification when two attributes of an entity shall be classified. The agreed solution, however, is to classify entity instances. Two options have been discussed. * Classify each entity type instance separately (using one or the other attribute), requiring two classification_assignments for one instance of view_definition_context. This way we can classify a view_definition_context instance as concept_stage AND maintenance. With 10 life cycle stage values and 20 application domain values this results in 30 classes. * Classify each common set of the attribute instances, requiring only one classification_assignment for one instance of view_definition_context. This way a view_definition_context instance is classified as the intesection between concept_stage and mechanical_domain, e.g. as concept_stage_maintenance. With 10 life cycle stage values and 20 application domain values this results in 200 classes. Our preference is the first option (Rob's Approaches #4) that will enable the allowed values of the life_cycle_stage and application_domain concepts to be explicitly recognized in the population as opposed to indirectly through a translation of the class name. To the second issue: Again two options seem to be discussed. * Classify a part id type with the identifier role as e.g. vendor_part_name or OEM_part_id_code, and hold an ontology in the RDL that structures the standardized values according name type class and code type class. The population will not explicitly show that the identifier is of type name or identifier code. * Classify the part id types as above, and classify the id type as name or identification_code explicitly in the population. Our preference is the second option (Rob's Approaches #4) that will allow a population that is most flexible for the different types of scenarios (see issue no 3). To the third issue: Again two options seem to be discussed. * Classify the entity type with no reference in the population to the superclass. This is ok as long as the translator integrates the RDL ontology (interactive or copy). * Classify the entity type class as a member of its superclass. This provides the population with explicit information about data type. Our preference is the second option (Rob's Approaches #4). This is the solution that appears best to satisfy the requirements of the 5 scenarios above. Best regards Leif & Trine _____ From: Rob Bodington [mailto:rob.bodington@eurostep.com] Sent: 2. februar 2005 11:40 To: 'Tim Turner'; 'David Price'; plcs-dex@lists.oasis-open.org Cc: 'Örjan Falk'; 'Jonas Rosén'; Tonning, Leif; 'Magnus Färneland' Subject: RE: [plcs-dex] Issues with identification and classification You are right Tim, we did discuss this, and the issue was the availability of the RDL, and the additional overhead of a translator accessing the RDL. In the implementation pilots there was concern that: a) the translator was going to have to query the RDL frequently and this would be an overhead. b) That an RDL server "May" not be available Hence the proposal. I agree about all concerns being made visible - I am trying to encourage everyone who is working on pilot implementations to join this email exploder. The /IGNORE is correct - in that it was agreed as the approach during the recent PLCS synchronization workshops. As a means of for deliberately saying "ignore" this. Regards Rob ------------------------------------------- Rob Bodington Eurostep Limited Web Page: <http://www.eurostep.com> http://www.eurostep.com <http://www.share-a-space.com> http://www.share-a-space.com Email: Rob.Bodington@eurostep.com Phone: +44 (0)1454 270030 Mobile: +44 (0)7796 176 401 -----Original Message----- From: Tim Turner [mailto:timturner11@bellsouth.net] Sent: 31 January 2005 18:32 To: 'David Price'; plcs-dex@lists.oasis-open.org Cc: 'Örjan Falk'; 'Jonas Rosén'; 'Tonning Leif'; 'Magnus Färneland' Subject: RE: [plcs-dex] Issues with identification and classification Ah - subclasses, ok. So, (with respect to your comment on Rob's suggestion) I presume that this information can be returned from an RDL query to determine whether the attribute value is an identification_code, a name, application_dmain, life_cycle_domain etc., right? I think all concerns should be made openly & visible to all. I will stand corrected, but mine was that in order to establish which identification_assignment applies to which view_definition_context attribute (application_domain or life_cycle_stage), we will require the results of the query above in order to make the determination. Tim -----Original Message----- From: David Price [mailto:david.price@eurostep.com] Sent: 31 January 2005 12:55 To: plcs-dex@lists.oasis-open.org Cc: 'Örjan Falk'; 'Jonas Rosén'; 'Tonning Leif'; 'Magnus Färneland' Subject: RE: [plcs-dex] Issues with identification and classification Hi Tim, Two comments... In the RDL you don't need class of class to solve this problem, subclassing will work. If we're going to assume no access to the RDL server is a concern, we might as well stop now. That said, the file can still parse... URIs are after all just text strings. Cheers, David -----Original Message----- From: Tim Turner [mailto:timturner11@bellsouth.net] Sent: 31 January 2005 15:29 To: 'David Price'; 'Rob Bodington'; plcs-dex@lists.oasis-open.org Cc: 'Örjan Falk'; 'Jonas Rosén'; 'Tonning Leif'; 'Magnus Färneland' Subject: RE: [plcs-dex] Issues with identification and classification Rob/Dave Didn't we discuss this issue of ambiguity once before? I can see both points & both have some (practical) observations; In Rob's version - using classification of classification is logically fine, but how many orders of classification are we going to allow? - wasn't this classification of concepts one of the reasons for having an RDL in the first place? - using classification of classification keeps the parsability with the P21/P28 file should an RDL not be available (for whatever reason) - we assume that the classification of another class always refers to the target External_class.name (& not to External_class.id, or External_class.description). In Dave's version - moving the classification to the RDL also makes sense & replaces the overhead from translators in reliance upon the RDL service - however, if for any reason the RDL service is unavailable, the file will not be parseable (as it will be inherently ambiguous) - which ought to be of practicable concern. Regards, Tim NB - I presume that the '/IGNORE' on instance #6 of Rob's diagrams should be a $ NNB - Most translators' default behaviour, given an attribute value of $, is that there was no data provided(!) so all this behaviour needs to be specifically coded & as generic as possible. -----Original Message----- From: David Price [mailto:david.price@eurostep.com] Sent: 31 January 2005 07:39 To: 'Rob Bodington'; plcs-dex@lists.oasis-open.org Cc: 'Örjan Falk'; 'Jonas Rosén'; 'Tonning, Leif'; 'Magnus Färneland' Subject: RE: [plcs-dex] Issues with identification and classification Rob, I think the fundamental approach here has a problem. Whether part_code is a kind of name or kind of identifier is schema-level information, not data exchange level information. Therefore, that statement has to be made within the RDL itself, not in the exchange file. How could a Web service present the possible types of names for something if that statement isn't in the RDL? Cheers, David -----Original Message----- From: Rob Bodington [mailto:rob.bodington@eurostep.com] Sent: 31 January 2005 07:28 To: plcs-dex@lists.oasis-open.org Cc: Örjan Falk; Jonas Rosén; Tonning, Leif; Magnus Färneland Subject: [plcs-dex] Issues with identification and classification Hi During the development of PLCS translators we have identified a couple of issues with the way in which we use classification of attribute and with the use of "role" in identification. I have documented what the issues are in the attached document and proposed a solution. Are the proposals acceptable to everyone? If so, we will need to modify the relevant capabilities. Regards Rob ------------------------------------------- Rob Bodington Eurostep Limited Web Page: http://www.eurostep.com http://www.share-a-space.com Email: Rob.Bodington@eurostep.com Phone: +44 (0)1454 270030 Mobile: +44 (0)7796 176 401 Fax: +44 (0)1454 270031 ************************************************************** Neither the confidentiality nor the integrity of this message can be vouched for following transmission on the Internet. All messages sent to a DNV email addressee are swept by Sybari Antigen for the presence of malicious code. DNV acknowledges that unsolicited email represents a potential security risk, and DNVs filters to block unwanted emails are therefore continuously adjusted. DNV has disabled "out of office" replies to Internet transmitted e-mail. **************************************************************
<<attachment: winmail.dat>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]