|
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
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.
-----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.
-----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
Didn't we discuss
this issue of ambiguity once before?
I can see both points
& both have some (practical) observations;
- 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).
- 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.
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.
**************************************************************
|