RE: Impact of XML on Data Modeling

I haven't found it practical to draw rigid distinctions between logical 
and physical models.  In general, if low-cost hardware could provide all 
the excellent response time, security etc. that we'd need without any 
optimization of physical storage or physical transmission, the physical 
model would always be the logical model, but since that rarely happens, 
they often are slightly different,  But the same formalisms can often be 
used for both logical and physical models.

To ground this in some of the work my colleagues and I are doing at IBM 
Research, we have developed strategies so that XPath addressing can be 
used against any kind of data, without it necessarily being converted as a 
whole into XML in advance.  We call this our Virtual XML work, and you can 
find an introduction to that work at 
http://www.research.ibm.com/journal/sj/452/rose.pdf .  See a trial, known 
as Virtual XML Garden, on the IBM alphaWorks site: 
http://www.alphaworks.ibm.com/tech/virtualxml .
In this case, the XML Schema is definitely being used as a logical model. 

Regarding conceptual models, I agree that they are most valuable when 
communicating with business or regulator stakeholders that you can't 
convene in a meeting for a syncronous dialog.  I think there is active 
work to decide if OWL can be represented as a conceptual model to people 
not familiar with its details, and I don't expect big progress on that 
front soon, but coupled with work to integrate OWL and XML (also 
speculative), could turn out to be useful.  Similar work has gone on 
around subsets of UML. 

One of the interesting things I am tracking is the use of structured 
natural language to do conceptual models.  For example, SBVR, recently 
published by the OMG, is an interesting example of this strategy. 

In the relational modeling world, there were clear procedures to refine 
logical models into physical models.  I think in the world of Web document 
and graph formats, there hasn't been as much rigor about specifying how to 
change a model without making it "no longer align" with the model one 
level above, or one level below, it.  I'm interested in this topic.

Because of the broad interest in SOA, I think a new frontier are tools 
that combine a data modeling perspective with a process modeling 
perspective.  I do expect various methodologies to be developed that 
address best ways to model both services, the set of operations they 
should provide, and the set of XML document formats they should receive 
and emit, trying to keep common cross-industry complex types in wide use 
(such as the OASIS Core Components or types from industry-standard 
vocabularies, like HL7 or ACORD).  For example, IBM's SOMA (mentioned a 
bit in 
http://www.ibm.com/developerworks/webservices/library/ws-soa-asset1/ ) is 
one such method. 

Regards,
Bob

manager, Scalable XML Infrastructure
IBM Thomas J Watson Research Center
http://www.research.ibm.com/XML






"Michael Kay" <mike@saxonica.com> 
Sent by: xmlschema-dev-request@w3.org
01/29/2008 10:58 AM

To
<abcoatesecure-w3c@yahoo.co.uk>, <xmlschema-dev@w3.org>
cc

Subject
RE: Impact of XML on Data Modeling







> So, what I should have said is that introducing "Person" as 
> the common superclass of "Employer" and "Employee" is 
> something you would normally do in the logical model, but you 
> would only do that in the conceptual model if the business 
> experts view the world that way.

What I usually find is that after a couple of hours with a whiteboard, you
change the way the business people see things. Suddenly they realize that
they have been using a word like "channel" (as in a broadcasting channel - 
a
real example) or "retailer" to mean three different things, and that this 
is
why they were getting confused... 

Similarly, when you start asking questions like "How do you handle a
customer who is also a supplier", you may well find one outpost of the
organization that tells you "we lump them together and call them business
partners", and then other people will say that's a good idea, we could do
that too.

So I don't really buy the idea that abstractions can be classified as
business-oriented or technically-oriented. They arise from designing
IT-enabled business processes, which tends to be a joint activity.


Michael Kay
http://www.saxonica.com/