Cart
[Home] [By Thread] [By Date] [Recent Entries]
++1 Too often I get schemas with serious scoping problems. They try to do too much and don't set the boundaries. We talk about use cases when we should be talking about job-at-hand. Instead of being explicit about the actual physical real actors in the transaction, they create a model of an actor and it is loose enough to take in so many actors that the job scope increases in unanticipated ways. Here is an example: "I want you to support HL7." "Which messages?" "I don't care. To pass certification, you have to support HL7." "Can you give me a list of the partners you will be exchanging these messages with?" "I don't want the system to restrict that. You have to support HL7." The old term for this is "boiling the ocean". len -----Original Message----- From: Simon St.Laurent [mailto:simonstl@s...] Sent: Saturday, October 04, 2008 8:12 PM To: Kurt Cagle Cc: Costello, Roger L.; xml-dev@l... Subject: Re: [Summary] Should Subject Matter Experts Determine XML Data Implementations? Kurt Cagle wrote: > In my experience designing ontologies for different groups, one thing > that I find keeps cropping up is that SMEs tend to create data > structures that most closely approximate their understanding of a > subject, not necessarily that provides the most optimal representation > of that data model. Certainly SMEs should be involved at all stages of > the ontology process, but I've also found that if left up to the SME > alone, the models are often awkward to implement, tend to be > overspecified, and as often as not contain sometimes bizarre assumptions > that can significantly limit these models when translated into a > computing environment. I have to agree with Kurt. Subject matter experts may well be experts at the subject, but making 'expert' data models work is not always a good idea. I'd probably go further, though. Frankly, when building data models, I'd much rather have a mix of skill levels and perspectives involved. Different participants have different views on the data, but there's often more than just views on the same data model - there are often different internalized data models. Combining those different models with data structures requires more than just careful data design. I'd argue it involves programming, transformations at minimum, that ensure that the data presented meets local expectations. That's never easy, but I don't think it's avoidable. It's been a long time since I've been involved with this in an XML context (though I'm starting to work with it in a database context again), so I'm a bit cautious about saying this. Nonetheless, it seems so obviously true to me that I might as well. Thanks, Simon St.Laurent XML retiree _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@l... subscribe: xml-dev-subscribe@l... List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
