OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm-ra] Rep of Description Class - Please review DCMI Abstract Model


With a little redrawing (not included here), the service description (SD) Figure 2 maps nicely into the DCMI resource model, Figure 1.  The mappings are:
. Resource =Value Object
. Property/value pair = Value Set
. name in SD should be changed to Property
. Semantics in SD is one of the Attributes contributing to the Value Set (Property/Value pair) instead of just the name (Property) as in DCMI because it is assumed the semantics of the pair is needed and a "joint" semantics description seems appropriate
. Also, Semantics in SD contributes directly to Value Object (Resource) instead of the class intermediary in DCMI because the DCMI model goes into more details of the semantics model;  SD assumes need to identify semantics but details of semantics modeling is out of scope.
. SD goes into variations of expressing Value Object (Property/Value pair) while DCMI holds this for its description model (Figure 2); same for any reference to syntax.
. SD includes attributes of provenance and value source which are not in DCMI models.

The DCMI description model models Property (name) to the left of statement, Value semantics to the right of statement, and Value syntax below statement.  These go into detail of structure I would be happy for the SD name (Property) and Value to reference or from which to derive more detailed example of syntax or semantics, but I'm not sure we want to take our discussion to that level because the DCMI model has this feel of intended completeness that I'm not convinced we should embrace.

In summary, the SD Figure 2 maps nicely to DCMI.  There are questions of scope when deciding what level of detail is appropriate for each, and SD could reference DCMI detail as a standard example without needlessly committing to that exclusively.  SD Figure 1 is dealing with a description other than strictly metadata and appears mostly orthogonal to DCMI except for the small part above statement in DCMI Figure 2.

This is also an interesting example of where you find a model/representation that has value but needs to be tailored or translated to another domain rather than just being adopted whole hog.  This brings us back to what we'll say about mediation.

Ken

On Mar 14, 2007, at 12:31 PM, Jeffrey A. Estefan wrote:

Ken,
 
With respect to the Representation of Description Class you have articulated in the RA, please review the following from Dublin Core Metadata Interchange (DCMI) abstract model, which is based on DCMI Element Set - ISO/IEC 15836 Std):
 
 
Please note Figs. 1 & 2.
 
Regards...
 
 - Jeff E.
 
 


------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305     phone:  703-983-7934
7515 Colshire Drive                        fax:        703-983-1379
McLean VA 22102-7508






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]