XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] Discover data patterns or Create data patterns?

Rather than "uncover patterns", I would say "formulate abstractions". But it
amounts to the same thing.

Aristotle said that you discover types by identifying sets of instances with
similar characteristics - there are lots of woolly things in that field,
let's call them sheep. Plato said that instances come into being by being
formed from types. Chicken or egg? Len will tell me I've got it all wrong...

Either way, data analysis is essentially an exercise in grouping objects
into types, and the people who do it best are those who are best at finding
useful abstractions. When the abstractions already exist in the outside
world, the data analyst can be said to be discovering them; when they don't,
he can be said to be inventing them. Usually it's a bit of both: when you
decide that "geographical region" is a useful concept to include in your
model, you can't claim to have invented the idea, but you will have to do a
lot of work to define precisely what you mean by it.

I don't think that the ability to formulate good abstractions can be taught
- but I think it can be learned.

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


> -----Original Message-----
> From: Costello, Roger L. [mailto:costello@mitre.org] 
> Sent: 20 September 2008 13:51
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] Discover data patterns or Create data patterns?
> 
> 
> Hi Folks,
> 
> Recently I read this:
> 
> "One of the most important axioms in the discipline of 
> Information Architecture states that designers are the ones 
> who uncover patterns inherent in data, and expose them in an 
> interface." [1]
> 
> I was particularly struck by these words: "uncover patterns 
> inherent in data".
> 
> I got to thinking, 
> 
>     - How does one uncover patterns in data? 
> 
>     - Does data have inherent patterns?
> 
>     - What is a data pattern?
> 
> I looked at regular expressions, e.g.
> 
>     [a-zA-Z]*[0-9]*
> 
> This regular expression specifies a "pattern"; namely zero or 
> more letters of the alphabet followed by zero or more digits.
> 
> This is a low-level pattern, at the character level.
> 
> What are patterns at the document level?
> 
> When I create an XML instance document I am (implicitly) stating,
>  
>    - Here is a data pattern I think is useful.
> 
> Do you agree?
> 
> For example, I discovered a pattern in BookStores: they are 
> comprised of multiple Books. And I discovered a pattern in 
> Books: they are comprised of a Title, an Author, a Date of 
> publication, an ISBN, and a Publisher. I can expose these 
> patterns like this:
> 
> <BookStore>
>      <Book>
>          <Title>The Art & Science of Web Design</Title>
>          <Author>Jeffrey Veen</Author>
>          <Date>2001</Date>
>          <ISBN>0-7897-2379-0</ISBN>
>          <Publisher>New Riders</Publisher>
>      </Book>
>      ...
> </BookStore>
> 
> QUESTIONS
> 
> 1. Are data patterns discovered, or, are data patterns created?
> 
> 2. Are data patterns descriptive, or, are data patterns prescriptive?
> 
> 3. What's the difference between a "master" data designer 
> versus a "novice" data designer? 
> 
> 4. Does this characterize the difference: a master data 
> designer discovers patterns intrinsic in data whereas a 
> novice data designer engineers a pattern?
> 
> 5. Are there steps that a person can take to transition from 
> a novice data designer to a master data designer?
> 
> /Roger
> 
> [1] The Art & Science of Web Design by Jeffrey Veen
> 
> ______________________________________________________________
> _________
> 
> 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@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org 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]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS