Reminder, blatant ad
dawn
notified of new postings using an atom feed, but I thought I'd make
another announcement here. There are now three entries in the series
starting with "Is Codd Dead?".
http://www.tincat-group.com/mewsings
Enjoy! --dawn
Jan Hidders
Since I don't like discussing by means of blog comments I'll post my
reaction here. As you probably know I'm in the pro-RM and anti-dbdebunk
camp, so although I'm probably mostly crticial, it is certainly not
meant as an attack.
Dawn Wolthuis wrote in her blog on
http://www.tincat-group.com/mewsings/2006/01/naked-model.html
the following:
>
> [...] If we were to implement a data model what would we have? Let's
> take a look at a recent definition of data model from Date.
>
> A data model is an abstract, self-contained, logical definition of
> the objects, operators, and so forth, that together constitute the
> abstract machine with which users interact. The objects allow us to
> model the structure of data. The operators allow us to model its
> behavior. (C. J. Date, An Introduction to Database Systems, Addison
> Wesley, 8e, 2003, p 15-16)
>
> I conclude from this that the implementation of a data model is a
> programming language, whether a general purpose programming language
> or not.
While I don't think that what you say here is strictly speaking
incorrect, I do believe that it is misleading. In programming languages
one is often rather more concrete about how the data is stored and how
the operators do their work, in fact that is often the whole purpose fo
the programming language, whereas Date stresses rightly here that it has
to be an *abstract* definition. Another important aspect is the extent
to which the definition is *logical*, which implies that the definition
of constraints and manipulations should be more declarative, whereas in
programming languages this is often more done in an operational way. Of
course there are no black and whites here because these things vary in
different programming languages, but simply equating the concept of
"data model" as Date and Codd define it and "programming language" is
cutting a few corners too many.
> My beef with the RM is related both to normalization theory as taught
> in colleges and universities, discussed in the Is Codd Dead? blog
> and to the way the RM, or parts thereof, are used in the practice of
> software development and maintenance today. It shapes the thinking of
> software developers in ways that are often not the most effective.
I have really no idea where this comes from. When I teach normalization
I do that in the context of the relational model. It is part of the
theory that you should know if you have to deal with an RDBMS.
Obviously, if you have to deal with another type of DBMS you should not
apply it, or at least not in exactly the same way. Are you now telling
me that most computer science students in the United States massively
fail to get this when they take their database courses? And those people
are allowed to build critical information systems? :-)
> And, by the way, if you are thinking that the RM need not be obvious
> in a developer's programming language but could be hidden behind the
> scenes, then my work is done. That would mean that no computer
> language would need to use the Information Principle, and neither you
> nor I would need to use the RM as a data model. We can use any
> programming language that does not represent itself as an
> implementation of the RM to employ an alternative data model.
Again, I have no idea what you are talking about here. Who on earth has
ever claimed that the RM would be the best data model for programming
languages? The claim of the RM is that it is a good data model for a
DBMS, and even that claim is usually qualified.
-- Jan Hidders
PS. Apologies in advance if I don't reply this week, I'll be mostly
off-line then.
dawn
Jan Hidders wrote:
> Hi Dawn,
>
> Since I don't like discussing by means of blog comments I'll post my
> reaction here.
I have never been a blog-comment person either, but since there are
some students reading my blog, it is good for them to see comments with
it too, so I'm encouraging that. I'm happy to get feedback from you in
this forum too, however.
> As you probably know I'm in the pro-RM and anti-dbdebunk
> camp, so although I'm probably mostly crticial, it is certainly not
> meant as an attack.
>
> Dawn Wolthuis wrote in her blog on
> http://www.tincat-group.com/mewsings/2006/01/naked-model.html
> the following:
> >
> > [...] If we were to implement a data model what would we have? Let's
> > take a look at a recent definition of data model from Date.
> >
> > A data model is an abstract, self-contained, logical definition of
> > the objects, operators, and so forth, that together constitute the
> > abstract machine with which users interact. The objects allow us to
> > model the structure of data. The operators allow us to model its
> > behavior. (C. J. Date, An Introduction to Database Systems, Addison
> > Wesley, 8e, 2003, p 15-16)
> >
> > I conclude from this that the implementation of a data model is a
> > programming language, whether a general purpose programming language
> > or not.
>
> While I don't think that what you say here is strictly speaking
> incorrect, I do believe that it is misleading. In programming languages
> one is often rather more concrete about how the data is stored and how
> the operators do their work, in fact that is often the whole purpose fo
> the programming language, whereas Date stresses rightly here that it has
> to be an *abstract* definition.
I definitely think that a data model is abstract. That is why I said
that an implementation of the data model (for our purposes of
developing software) is a programming language. That is why when
countering SQL, claiming it not to be a good implementation of the RM,
Date introduces Tutorial-D, another language. I am stating that a data
model is the abstraction of a programming language (or sublanguage).
> Another important aspect is the extent
> to which the definition is *logical*, which implies that the definition
> of constraints and manipulations should be more declarative,
I suppose that is the intent, but I see nothing in Codd's definition of
a data model that would lead me to believe that a data model must be
implemented in a declarative language.
> whereas in
> programming languages this is often more done in an operational way.
OK-ish.
> Of
> course there are no black and whites here because these things vary in
> different programming languages, but simply equating the concept of
> "data model" as Date and Codd define it and "programming language" is
> cutting a few corners too many.
I did not intend to equate them but to claim that a data model is
implemented via a programming language. That language could be
declarative, functional, set-based, procedural, OO, ...
> > My beef with the RM is related both to normalization theory as taught
> > in colleges and universities, discussed in the Is Codd Dead? blog
> > and to the way the RM, or parts thereof, are used in the practice of
> > software development and maintenance today. It shapes the thinking of
> > software developers in ways that are often not the most effective.
>
> I have really no idea where this comes from. When I teach normalization
> I do that in the context of the relational model. It is part of the
> theory that you should know if you have to deal with an RDBMS.
> Obviously, if you have to deal with another type of DBMS you should not
> apply it,
and that is obvious to your students? If so, three cheers.
> or at least not in exactly the same way. Are you now telling
> me that most computer science students in the United States massively
> fail to get this when they take their database courses?
I cannot speak for most students, but when looking at text books
(rather than listening to professors) and to employees entering a space
where they need not employ the RM, it is my guess that the bulk of the
college grads in CS in the US think that the RM is the way one should
model data, period.
> And those people
> are allowed to build critical information systems? :-)
Not until we have beat the theory out of them and introduced them to
the real world :-) [P.S. Don't quote me on that -- this is a private
conversation, right?]
> > And, by the way, if you are thinking that the RM need not be obvious
> > in a developer's programming language but could be hidden behind the
> > scenes, then my work is done. That would mean that no computer
> > language would need to use the Information Principle, and neither you
> > nor I would need to use the RM as a data model. We can use any
> > programming language that does not represent itself as an
> > implementation of the RM to employ an alternative data model.
>
> Again, I have no idea what you are talking about here. Who on earth has
> ever claimed that the RM would be the best data model for programming
> languages?
I didn't intend to suggest that. Whenever I mention that I want to
work with such data structures as ordered lists with associated insert
and delete functions, I am informed that I am talking about
representation and that what I want is possible with the data modeled
via the RM and then handled with another product in front of that. I'm
showing that the RM is all about representation. As soon as you decide
to use another representation, you are moving away from the RM.
> The claim of the RM is that it is a good data model for a
> DBMS,
Yes, that is the claim. I'm claiming in this blog that it isn't
necessary, a point that no one contests (I suspect) since we know we
can build software systems without it. I don't think many will contest
the claim that is it not sufficient either. But (I think) I'm going to
claim that there other data models that are sufficient for developing
software and then ask if it is important enough to use the RM that we
want to suffer the mismatch with whatever other data models we use.
> and even that claim is usually qualified.
>
> -- Jan Hidders
>
> PS. Apologies in advance if I don't reply this week, I'll be mostly
> off-line then.
No problem. --dawn
mAsterdam
Anecdote time:
When I learned about normalisation in 1984 in a post-doc
IT curriculum, we were to some extend free to do our own
explorations. One nice, enlightening excercise was this one:
From a normalised data model (based on an earlier
design case, so "real" - or at least our own - analysis,
complete with interviews, prioritisation, integration etcetera -
remember James Martins integration bubble charts?) we made,
in several workgroups, different implementation plans:
one for a purely batch processing (only sequential files)
environment, one for ISAM/online, (we skipped RDBMS
implementation as being both being trivial and not yet
feasible for performance reasons at that time :-), and
eventually one hybrid plan.
Some crucial parts of those plans were actually coded and
tested later in the course.
One thing I learned was that when you get your data right,
you can pretty much build a working system with any
tools available. A DBMS just makes the job easier.
Database: Find the base for your design in data.
In short: To me the connection between RM and
normalisation is mainly historical.
Jan Hidders
That's not how I would formulate it. SQL is not an implementation of a
data model, it *is* a data model (as defined above by Chris Date). SQL
and the relational model are at the same abstraction level, so it
doesn't make much sense to me to say that one would be an implementation
of the other. In the same way I don't see what the data model of, say,
Java would be, and what it would abstract from i.e. what it leaves out.
If I take the definitions of the objects, operators and everything that
makes up the abstract machine that the user / programmer of Java
interacts with, (not to be confuseed with the JVM) that *is* the
definition of Java. To me it seems absurd to say that a data model is an
abstraction of a programming language.
>>>My beef with the RM is related both to normalization theory as taught
>>>in colleges and universities, discussed in the Is Codd Dead? blog
>>>and to the way the RM, or parts thereof, are used in the practice of
>>>software development and maintenance today. It shapes the thinking of
>>>software developers in ways that are often not the most effective.
>>
>>I have really no idea where this comes from. When I teach normalization
>>I do that in the context of the relational model. It is part of the
>>theory that you should know if you have to deal with an RDBMS.
>>Obviously, if you have to deal with another type of DBMS you should not
>>apply it,
>
> and that is obvious to your students? If so, three cheers.
Might have to do with the fact that we also teach some stuff on other
types of databases, object-oriented and object-relational in the past,
now mostly XML databases. And, of course, Belgian students are
incredibly smart. :-)
> [...] Whenever I mention that I want to
> work with such data structures as ordered lists with associated insert
> and delete functions, I am informed that I am talking about
> representation and that what I want is possible with the data modeled
> via the RM and then handled with another product in front of that. I'm
> showing that the RM is all about representation. As soon as you decide
> to use another representation, you are moving away from the RM.
I don't know who told you that lists are somehow only representation
while sets are not, but that is nonsense. The reason to avoid lists is
far more mundane and practical; it would make the DBMS more complex and
make tasks such as query optimization, concurrency control and integrity
maintenance harder. It would also make the theory more complex, which in
the long term usually also translates into practical problems.
>>The claim of the RM is that it is a good data model for a
>>DBMS,
>
> Yes, that is the claim. I'm claiming in this blog that it isn't
> necessary, a point that no one contests (I suspect) since we know we
> can build software systems without it.
Sure, bathing regularly is also not necessary. It's still a good idea
though. :-)
-- Jan Hidders
dawn
Both SQL and QUEL were implementations based (however loosely) on the
Relational Model. So, a single data model can have multiple
implementations. Similarly an oject data model can be implemented by
both Java and C++ in different ways, with varying degress of purity.
> SQL
> and the relational model are at the same abstraction level,
An instance of the SQL programming language (e.g. SQL as implemented in
Oracle 8i) is an implementation, an actual language that I can use to
perform a query against a database.
> so it
> doesn't make much sense to me to say that one would be an implementation
> of the other. In the same way I don't see what the data model of, say,
> Java would be, and what it would abstract from i.e. what it leaves out.
> If I take the definitions of the objects, operators and everything that
> makes up the abstract machine that the user / programmer of Java
> interacts with, (not to be confuseed with the JVM) that *is* the
> definition of Java. To me it seems absurd to say that a data model is an
> abstraction of a programming language.
Multiple programming languages, each with a different syntax, can each
implement the same data model, wouldn't you say? Maybe "implement" is
too strong. SQL, QUEL, and Tutorial-D can all be based on the RM. The
RM is the abstraction and each of these others has a different syntax.
> >>>My beef with the RM is related both to normalization theory as taught
> >>>in colleges and universities, discussed in the Is Codd Dead? blog
> >>>and to the way the RM, or parts thereof, are used in the practice of
> >>>software development and maintenance today. It shapes the thinking of
> >>>software developers in ways that are often not the most effective.
> >>
> >>I have really no idea where this comes from. When I teach normalization
> >>I do that in the context of the relational model. It is part of the
> >>theory that you should know if you have to deal with an RDBMS.
> >>Obviously, if you have to deal with another type of DBMS you should not
> >>apply it,
> >
> > and that is obvious to your students? If so, three cheers.
>
> Might have to do with the fact that we also teach some stuff on other
> types of databases, object-oriented and object-relational in the past,
> now mostly XML databases. And, of course, Belgian students are
> incredibly smart. :-)
I knew that. They are close to those Dutch folks.
> > [...] Whenever I mention that I want to
> > work with such data structures as ordered lists with associated insert
> > and delete functions, I am informed that I am talking about
> > representation and that what I want is possible with the data modeled
> > via the RM and then handled with another product in front of that. I'm
> > showing that the RM is all about representation. As soon as you decide
> > to use another representation, you are moving away from the RM.
>
> I don't know who told you that lists are somehow only representation
> while sets are not, but that is nonsense.
Agreed.
> The reason to avoid lists is
> far more mundane and practical; it would make the DBMS more complex and
> make tasks such as query optimization, concurrency control and integrity
> maintenance harder.
Harder for whom?
> It would also make the theory more complex, which in
> the long term usually also translates into practical problems.
The language I speak also has a very complicated theory behind it, if
any at all (IIRC Chomsky or others have worked on a mathematical theory
behind languages). But it still might make sense for me to speak it.
> >>The claim of the RM is that it is a good data model for a
> >>DBMS,
> >
> > Yes, that is the claim. I'm claiming in this blog that it isn't
> > necessary, a point that no one contests (I suspect) since we know we
> > can build software systems without it.
>
> Sure, bathing regularly is also not necessary. It's still a good idea
> though. :-)
Yup. So, that is what we are left with -- decisions on whether it is
obvious to bathe regularly or not, or maybe it is more like curling
your hair with a curling iron. It might make complete sense to a whole
group of women, but it has never made sense to me and I get ready much
faster ignoring it altogether. cheers! --dawn
Jan Hidders
Not in that sense. Your example is not a really good one because the RM
is strictly speaking not a data model (using Date's definition) but
rather a description of a class of data models. It lists some
requirements, and sketches a few things, but doesn't exactly define how
the abstract machine looks and what the complete set of operations is.
> Similarly an oject data model can be implemented by
> both Java and C++ in different ways, with varying degress of purity.
Not in the definition of data model that we are using at the moment.
The semantics of Java and C++ describe different state machines and
different operations, so they define different data models. Of course
there are some comonalities and things they share, but that is
different from saying they represent the same data model.
> > SQL
> > and the relational model are at the same abstraction level,
>
> An instance of the SQL programming language (e.g. SQL as implemented in
> Oracle 8i) is an implementation, an actual language that I can use to
> perform a query against a database.
Yes, but a particular implementation is yet again at another lower
abstraction level.
Perhaps there is a small lesson here. Saying that A is an abstraction
of B, or that A is abstract is meaningless until you have explain in
what way exactly you are abstracting or what it is that you are
abstracting from.
> > > [...] Whenever I mention that I want to
> > > work with such data structures as ordered lists with associated insert
> > > and delete functions, I am informed that I am talking about
> > > representation and that what I want is possible with the data modeled
> > > via the RM and then handled with another product in front of that. I'm
> > > showing that the RM is all about representation. As soon as you decide
> > > to use another representation, you are moving away from the RM.
> >
> > I don't know who told you that lists are somehow only representation
> > while sets are not, but that is nonsense.
>
> Agreed.
I currently do some research in bioinformatics. Lists of nucleotides
and proteins all over the place, and measurement series are also very
often much more naturally represented as lists.
> > The reason to avoid lists is
> > far more mundane and practical; it would make the DBMS more complex and
> > make tasks such as query optimization, concurrency control and integrity
> > maintenance harder.
>
> Harder for whom?
The implementors of the DBMS. And if their job gets hard that leads to
more missed opportunities for the query optimizer so slower
performance, more difficult algorithms for concurrency control that
allows less concurrency, and more overhead for more complex integrity
constraints.
> > It would also make the theory more complex, which in
> > the long term usually also translates into practical problems.
>
> The language I speak also has a very complicated theory behind it, if
> any at all (IIRC Chomsky or others have worked on a mathematical theory
> behind languages). But it still might make sense for me to speak it.
That's because you don't have to build the Language Management System
as they already exist. But if you were faced with the task of designing
such language processing systems from scratch then you would probably
try to design this language as simple as possible, but, to paraphrase
Einstein, not simpeler.
-- Jan Hidders
PS. I'm really signing off now as my train leaves within a few hours.
Expect a reply after a week or so.
dawn
Because I was making an effort to get a handle on the term "data model"
as found in the phrase "Relational Data Model" I'm working with a
different "data model" than you are. Mine is more abstract (or as you
stated, it is a description of a class of data models). Using the term
the way I am using it, you can have a "Relational Data Model" and an
"Object Data Model," for example. Can you name a bunch of data models
using your definition?
> Of course
> there are some comonalities and things they share, but that is
> different from saying they represent the same data model.
>
> > > SQL
> > > and the relational model are at the same abstraction level,
> >
> > An instance of the SQL programming language (e.g. SQL as implemented in
> > Oracle 8i) is an implementation, an actual language that I can use to
> > perform a query against a database.
>
> Yes, but a particular implementation is yet again at another lower
> abstraction level.
And a data model is at a higher level of abstraction. Again, recall
that I was trying to get a handle on the meaning of "Relational Data
Model." What is this "data model" when you remove the adjective? It
is more abstract that what you are referring to.
> Perhaps there is a small lesson here. Saying that A is an abstraction
> of B, or that A is abstract is meaningless until you have explain in
> what way exactly you are abstracting or what it is that you are
> abstracting from.
It isn't meaningless, but it isn't very helpful simply to state that
something is an abstraction of something else. It is a bit more
concrete to state that something is an implementation of something
else. So if you take Relational Data Model and want to get a handle on
this data model, you can at least see that if you were to implement it,
you would have a programming language (or sublanguage).
> > > > [...] Whenever I mention that I want to
> > > > work with such data structures as ordered lists with associated insert
> > > > and delete functions, I am informed that I am talking about
> > > > representation and that what I want is possible with the data modeled
> > > > via the RM and then handled with another product in front of that. I'm
> > > > showing that the RM is all about representation. As soon as you decide
> > > > to use another representation, you are moving away from the RM.
> > >
> > > I don't know who told you that lists are somehow only representation
> > > while sets are not, but that is nonsense.
> >
> > Agreed.
>
> I currently do some research in bioinformatics. Lists of nucleotides
> and proteins all over the place, and measurement series are also very
> often much more naturally represented as lists.
Perhaps you are beyond me on that one. I've read Bioinformatics for
Dummies ;-)
> > > The reason to avoid lists is
> > > far more mundane and practical; it would make the DBMS more complex and
> > > make tasks such as query optimization, concurrency control and integrity
> > > maintenance harder.
> >
> > Harder for whom?
>
> The implementors of the DBMS.
BINGO! Having been on the applications side of the house, I am aware
that choices are made on user interface design decisions are sometimes
made due to the cost of implementation or support for the developers.
But for an entire industry to fix on that strategy when the user is a
programmer is really dreadful. It seems someone could look at how to
make the end-user (in this case a software developer) as productive as
possible.
> And if their job gets hard that leads to
> more missed opportunities for the query optimizer so slower
> performance,
That would make more sense to me if I did not work with a non-1NF
(non-relational) product that provides good performance.
> more difficult algorithms for concurrency control that
> allows less concurrency, and more overhead for more complex integrity
> constraints.
That one I agree with.
> > > It would also make the theory more complex, which in
> > > the long term usually also translates into practical problems.
> >
> > The language I speak also has a very complicated theory behind it, if
> > any at all (IIRC Chomsky or others have worked on a mathematical theory
> > behind languages). But it still might make sense for me to speak it.
>
> That's because you don't have to build the Language Management System
> as they already exist. But if you were faced with the task of designing
> such language processing systems from scratch then you would probably
> try to design this language as simple as possible, but, to paraphrase
> Einstein, not simpeler.
Then there is that philosophy of making products easy for users. The
RM isn't getting us there it seems. Cheers! --dawn
> -- Jan Hidders
>
> PS. I'm really signing off now as my train leaves within a few hours.
> Expect a reply after a week or so.
Have a good trip. (Or, rather, I hope you had a good trip and enjoyed
your time away from the screen and keyboard.)
JOG
[snip]
> > [...] Whenever I mention that I want to
> > work with such data structures as ordered lists with associated insert
> > and delete functions, I am informed that I am talking about
> > representation and that what I want is possible with the data modeled
> > via the RM and then handled with another product in front of that. I'm
> > showing that the RM is all about representation. As soon as you decide
> > to use another representation, you are moving away from the RM.
>
> I don't know who told you that lists are somehow only representation
> while sets are not, but that is nonsense. The reason to avoid lists is
> far more mundane and practical; it would make the DBMS more complex and
> make tasks such as query optimization, concurrency control and integrity
> maintenance harder. It would also make the theory more complex, which in
> the long term usually also translates into practical problems.
I do not agree with this. Conventional ordering (and hence listing) is
mathematically impossible in the relational model period, due to the
Codd's redefinition of RM-relations and the model's closure. Dawn is
hence correct imo - lists must be interpreted by a process external to
the RM, not for the sake of simplicity, or query optimization, but
rather because the very the nature of that data model precludes their
implementation.
dawn
I agree (I guess it makes sense that I would agree with you agreeing
with me). While ordering functions (SORT) may be defined on sets,
those are orderings on values. There is no ordering within the
relational structure itself.
Of course you can simulate an ordered list using relations by adding in
ordering attributes and related functions such as insert & delete.
That could all be done behind the scenes without the programmer
touching the ordering attribute at all. But once the interface to the
user (programmer) has these features, it is no longer an RM interface
because it supports ordered lists. --dawn
Jon Heggland
j...@cs.nott.ac.uk says...
> Jan Hidders wrote:
> [snip]
> I do not agree with this. Conventional ordering (and hence listing) is
> mathematically impossible in the relational model period, due to the
> Codd's redefinition of RM-relations and the model's closure.
Can you elaborate on this? I can't immediately see why lists are harder
than arrays, special cases of which even today's SQL systems can handle.
> Dawn is
> hence correct imo - lists must be interpreted by a process external to
> the RM, not for the sake of simplicity, or query optimization, but
> rather because the very the nature of that data model precludes their
> implementation.
...though of course if you view the type system as "external to the RM",
you are correct---but I don't really see the point of the argument in
that case.
--
Jon
Todd
I do respect many of your opinions, but maybe you could give me more
insight. It seems in many of your past postings, that:
1) You think that throwing data control (I mean real life 'facts' here,
not bits on a hard drive) into the domain of the developer (who is a
person that really has no connection with the data) is a good thing.
In other words,
Me: 'Hey, developer, build me a sandwich'
D: 'OK, I can do that, what do you have in the fridge?'
Me: 'I don't know, go look at it and figure it out. Oh, and here's a
knife if you need it'
D: 'Hmm, OK I'll do my best. Did you want mustard with that? Maybe
you might want to know if somebody else wants mustard? Wait a second
... is there somebody else?'
Me: 'Well, that's not important right now, is it?'
2) You seem to sing 'convenience' in many of your posts (under the
hoods). Personally, and perhaps unfortunately, I think we can't always
be convenient when it comes to modelling reality.
3) It's almost like you're trying to say that RM is this thing that we
have to 'put up' with. You could be correct in a 'convenient' way, but
wrong in a 'correct' way. Think about it.
4) Keep up the discussion. I enjoy it immensely. I'll certainly be
perusing your blog every now and again.
Todd
dawn
Todd wrote:
> Hello Dawn,
>
> I do respect many of your opinions, but maybe you could give me more
> insight. It seems in many of your past postings, that:
>
> 1) You think that throwing data control (I mean real life 'facts' here,
> not bits on a hard drive) into the domain of the developer (who is a
> person that really has no connection with the data) is a good thing.
Perhaps we need to define developer. I am calling anyone who is
developing software a "developer." Perhaps we need to define software?
It is everything "stored on" a computer that is not hardware. Does
that work for you? That would be "soft stuff" that can change,
compared to the hardware. I haven't thought long and hard about that
definition, but that is how I perceive it.
Some parts of this software could be like propositions that can be used
as input or output, while other aspects of this software could be
functions that operate on input to produce output. But it's all
software.
> In other words,
>
> Me: 'Hey, developer, build me a sandwich'
--d: smile when you call me that
> D: 'OK, I can do that, what do you have in the fridge?'
--d: how hungry are you? are you a vegetarian? do you prefer whole
wheat? Does anyone else need a sandwich? ...more attempts to ascertain
requirements.
> Me: 'I don't know, go look at it and figure it out. Oh, and here's a
> knife if you need it'
--d: at this point I tell you to make it yourself, but I'll play along
> D: 'Hmm, OK I'll do my best. Did you want mustard with that? Maybe
> you might want to know if somebody else wants mustard? Wait a second
> ... is there somebody else?'
I know I'll often miss something in spite of considerable efforts in
requirements elicitation, but hopefully not something that big.
> Me: 'Well, that's not important right now, is it?'
Sure it is. I might have to be careful how much of the cheese I use up
on your sandwich.
> 2) You seem to sing 'convenience' in many of your posts (under the
> hoods).
Productivity for software developers as users of various tools. If you
call that convenience...
> Personally, and perhaps unfortunately, I think we can't always
> be convenient when it comes to modelling reality.
No, but we can usually improve on user experience and productivity when
we decide those are important.
> 3) It's almost like you're trying to say that RM is this thing that we
> have to 'put up' with.
In fact, I think it is something that we DON'T have to put up with ;-)
> You could be correct in a 'convenient' way, but
> wrong in a 'correct' way. Think about it.
Oh, you know I do.
> 4) Keep up the discussion. I enjoy it immensely. I'll certainly be
> perusing your blog every now and again.
Thanks, Todd. Cheers! --dawn
> Todd
Leif B. Kristensen
> Perhaps we need to define developer. I am calling anyone who is
> developing software a "developer." Perhaps we need to define
> software?
> It is everything "stored on" a computer that is not hardware. Does
> that work for you? That would be "soft stuff" that can change,
> compared to the hardware. I haven't thought long and hard about that
> definition, but that is how I perceive it.
That definition would of course aso include the "end user" who only
punches data into a shrink-wrapped software package. In my view, a
"developer" should be one who is making software. You may of course
include the end users who produce nifty macros to facilitate daily
work. The border is certainly a fluid one. Most of us have started as
"end users", I guess.
--
Leif Biberg Kristensen
http://solumslekt.org/
dawn
Leif B. Kristensen wrote:
> dawn skrev:
>
> > Perhaps we need to define developer. I am calling anyone who is
> > developing software a "developer."
I still agree with myself on this one
> Perhaps we need to define
> > software?
> > It is everything "stored on" a computer that is not hardware. Does
> > that work for you? That would be "soft stuff" that can change,
> > compared to the hardware. I haven't thought long and hard about that
> > definition, but that is how I perceive it.
>
> That definition would of course aso include the "end user" who only
> punches data into a shrink-wrapped software package. In my view, a
> "developer" should be one who is making software.
That is my view as well and I see where my definitions are not tight
enough to make that clear. If someone is using software, providing
input or using output, but not developing any functions, then I guess I
would say they are not developing software. However, if that input is
in the form of specs... (e.g. the user type in a bunch of xml documents
and dtds and then clicks a button to generate an application), then
what?
Anyway, I'm good with saying that a developer is someone developing
software, I'm not as happy with the definiion of software. What is a
nice crisp definition of software?
> You may of course
> include the end users who produce nifty macros to facilitate daily
> work. The border is certainly a fluid one. Most of us have started as
> "end users", I guess.
And developers are end-users of language compilers, interpreters, dbms
interfaces, etc.
Cheers! --dawn
Todd
> Todd wrote:
> > 1) You think that throwing data control (I mean real life 'facts' here,
> > not bits on a hard drive) into the domain of the developer (who is a
> > person that really has no connection with the data) is a good thing.
>
> Perhaps we need to define developer. I am calling anyone who is
> developing software a "developer." Perhaps we need to define software?
> It is everything "stored on" a computer that is not hardware. Does
> that work for you? That would be "soft stuff" that can change,
> compared to the hardware. I haven't thought long and hard about that
> definition, but that is how I perceive it.
What works for you then? Flexibility or stability? Can we achieve
both? Don't get me wrong. I think you are flexing some good muscle.
>
> Some parts of this software could be like propositions that can be used
> as input or output, while other aspects of this software could be
> functions that operate on input to produce output. But it's all
> software.
>
> > In other words,
> >
> > Me: 'Hey, developer, build me a sandwich'
>
> --d: smile when you call me that
Coincidence. D was supposed to mean Developer, not Dawn. Sorry about
that if you took it that way.
> > D: 'OK, I can do that, what do you have in the fridge?'
>
> --d: how hungry are you? are you a vegetarian? do you prefer whole
> wheat? Does anyone else need a sandwich? ...more attempts to ascertain
> requirements.
>
> > Me: 'I don't know, go look at it and figure it out. Oh, and here's a
> > knife if you need it'
>
> --d: at this point I tell you to make it yourself, but I'll play along
>
> > D: 'Hmm, OK I'll do my best. Did you want mustard with that? Maybe
> > you might want to know if somebody else wants mustard? Wait a second
> > ... is there somebody else?'
>
> I know I'll often miss something in spite of considerable efforts in
> requirements elicitation, but hopefully not something that big.
>
> > Me: 'Well, that's not important right now, is it?'
>
> Sure it is. I might have to be careful how much of the cheese I use up
> on your sandwich.
Well, I suppose I was getting at the fact that it seems that some of
what you suggest screams lack of data integrity, and in trying to get
that point across, I dropped into a client situation (the dialog above
would have me as the client) which is frequent in any kind of database
design. I was simply trying to say that some of what you suggest may
be putting a scarier load on the developer. Chaos where something
should be stable. Initial condition: client gives you bad data, or no
data; client gives you bad metadata; Result: chaos gives you a terrible
headache as everything may spin out of control. Sensitivity to initial
conditions, you get the idea...
> > 2) You seem to sing 'convenience' in many of your posts (under the
> > hoods).
>
> Productivity for software developers as users of various tools. If you
> call that convenience...
Productivity. What is that exactly. I assume you mean that developers
make money for a small amount of time spent, ease of maintenance of
software, blah blah. Well, at this point, I still need some
convincing.
> > Personally, and perhaps unfortunately, I think we can't always
> > be convenient when it comes to modelling reality.
>
> No, but we can usually improve on user experience and productivity when
> we decide those are important.
>
> > 3) It's almost like you're trying to say that RM is this thing that we
> > have to 'put up' with.
>
> In fact, I think it is something that we DON'T have to put up with ;-)
>
> > You could be correct in a 'convenient' way, but
> > wrong in a 'correct' way. Think about it.
>
> Oh, you know I do.
>
> > 4) Keep up the discussion. I enjoy it immensely. I'll certainly be
> > perusing your blog every now and again.
BTW, this was not meant as a jibe. I really am interested in what you
have to say.
dawn
Todd wrote:
> dawn wrote:
> > Todd wrote:
> > > 1) You think that throwing data control (I mean real life 'facts' here,
> > > not bits on a hard drive) into the domain of the developer (who is a
> > > person that really has no connection with the data) is a good thing.
> >
> > Perhaps we need to define developer. I am calling anyone who is
> > developing software a "developer." Perhaps we need to define software?
> > It is everything "stored on" a computer that is not hardware. Does
> > that work for you? That would be "soft stuff" that can change,
> > compared to the hardware. I haven't thought long and hard about that
> > definition, but that is how I perceive it.
>
> What works for you then? Flexibility or stability?
Yes. And the needs for each must be taken into account when assessing
risks. Sometimes there is a need for such incredible stability that
you would not want to risk any instability for a little flexibility.
You still would want optimal flexibility within your extreme stability,
however.
> Can we achieve
> both? Don't get me wrong. I think you are flexing some good muscle.
>
> >
> > Some parts of this software could be like propositions that can be used
> > as input or output, while other aspects of this software could be
> > functions that operate on input to produce output. But it's all
> > software.
> >
> > > In other words,
> > >
> > > Me: 'Hey, developer, build me a sandwich'
> >
> > --d: smile when you call me that
>
> Coincidence. D was supposed to mean Developer, not Dawn. Sorry about
> that if you took it that way.
Ah, yes, I misinterpreted, but since I'm from the developer side of the
house (if we must choose sides), that read OK.
> > > D: 'OK, I can do that, what do you have in the fridge?'
> >
> > --d: how hungry are you? are you a vegetarian? do you prefer whole
> > wheat? Does anyone else need a sandwich? ...more attempts to ascertain
> > requirements.
> >
> > > Me: 'I don't know, go look at it and figure it out. Oh, and here's a
> > > knife if you need it'
> >
> > --d: at this point I tell you to make it yourself, but I'll play along
> >
> > > D: 'Hmm, OK I'll do my best. Did you want mustard with that? Maybe
> > > you might want to know if somebody else wants mustard? Wait a second
> > > ... is there somebody else?'
> >
> > I know I'll often miss something in spite of considerable efforts in
> > requirements elicitation, but hopefully not something that big.
> >
> > > Me: 'Well, that's not important right now, is it?'
> >
> > Sure it is. I might have to be careful how much of the cheese I use up
> > on your sandwich.
>
> Well, I suppose I was getting at the fact that it seems that some of
> what you suggest screams lack of data integrity,
I understand why you say that. There is more than one way to achieve
data integrity, however. There are also many different aspects to data
integrity. A system designed to handle only the "most prevelent color"
(or some other attribute) rather than a list of colors because that
would be less expensive is sacrificing data integrity, perhaps with a
good business case for doing so when the DBMS doesn't support attribute
lists.
> and in trying to get
> that point across, I dropped into a client situation (the dialog above
> would have me as the client) which is frequent in any kind of database
> design. I was simply trying to say that some of what you suggest may
> be putting a scarier load on the developer.
Yup, I followed your reasoning.
> Chaos where something
> should be stable. Initial condition: client gives you bad data, or no
> data; client gives you bad metadata; Result: chaos gives you a terrible
> headache as everything may spin out of control. Sensitivity to initial
> conditions, you get the idea...
I understand that different things are scary when choosing different
toolsets. There are tradeoffs.
>
> > > 2) You seem to sing 'convenience' in many of your posts (under the
> > > hoods).
> >
> > Productivity for software developers as users of various tools. If you
> > call that convenience...
>
> Productivity. What is that exactly.
More, better, faster. An individual or team is able to accomplish more
with less, for the long haul.
> I assume you mean that developers
> make money for a small amount of time spent, ease of maintenance of
> software, blah blah. Well, at this point, I still need some
> convincing.
I would expect as much.
> > > Personally, and perhaps unfortunately, I think we can't always
> > > be convenient when it comes to modelling reality.
> >
> > No, but we can usually improve on user experience and productivity when
> > we decide those are important.
> >
> > > 3) It's almost like you're trying to say that RM is this thing that we
> > > have to 'put up' with.
> >
> > In fact, I think it is something that we DON'T have to put up with ;-)
> >
> > > You could be correct in a 'convenient' way, but
> > > wrong in a 'correct' way. Think about it.
> >
> > Oh, you know I do.
> >
> > > 4) Keep up the discussion. I enjoy it immensely. I'll certainly be
> > > perusing your blog every now and again.
>
> BTW, this was not meant as a jibe.
No problem at all -- I didn't take it that way.
> I really am interested in what you
> have to say.
Much appreciated. Thanks. --dawn
x
"dawn" <dawnwo...@gmail.com> wrote in message
news:1138382966.6...@g47g2000cwa.googlegroups.com...
Talking about the relational model of data and the "list model of data"
instead of the relational data model and the "list data model" what is the
advantage of one over the other when modeling the following problems:
a) The problem is naturally formulated in terms of named lists of items and
lists operations.
How would you implement this with sets and sets operations ?
b) The problem is naturally formulated in terms of named sets of items and
set operations.
How would you implement this with lists and lists operations ?
c) The problem is naturally formulated in terms of sets and lists with their
operations.
How would you implement this with lists and lists operations ?
How would you implement this with sets and sets operations ?
There is a need for an efficient model to support both sets and lists ?
What are the basic operations for combining lists and sets ?
Where do we stop ? Why not asking for a model to support all mathematics ?
x
"x" <x...@not-exists.org> wrote in message
news:drkjmn$eae$1...@domitilla.aioe.org...
> What are the basic operations for combining lists and sets ?
And what is the result of such an operation ? A list ? A set ?
x
>
> Leif B. Kristensen wrote:
> > dawn skrev:
> >
> > > Perhaps we need to define developer. I am calling anyone who is
> > > developing software a "developer."
>
> I still agree with myself on this one
>
> > Perhaps we need to define
> > > software?
> > > It is everything "stored on" a computer that is not hardware. Does
> > > that work for you? That would be "soft stuff" that can change,
> > > compared to the hardware. I haven't thought long and hard about that
> > > definition, but that is how I perceive it.
> >
> > That definition would of course aso include the "end user" who only
> > punches data into a shrink-wrapped software package. In my view, a
> > "developer" should be one who is making software.
> That is my view as well and I see where my definitions are not tight
> enough to make that clear. If someone is using software, providing
> input or using output, but not developing any functions, then I guess I
> would say they are not developing software. However, if that input is
> in the form of specs... (e.g. the user type in a bunch of xml documents
> and dtds and then clicks a button to generate an application), then
> what?
> Anyway, I'm good with saying that a developer is someone developing
> software, I'm not as happy with the definiion of software. What is a
> nice crisp definition of software?
Do you think of a virtual machine as software or hardware ?
Software = ware that can be easily changed and provide a function only when
used with some hardware.
Hardware= ware that is hard to change and provide a function only when used
with some software.
The soft or hard quality is relative.
For example the mathematics is hardware ;-)
dawn
software
> Software = ware that can be easily changed and provide a function only when
> used with some hardware.
It would be great if software could be defined as being easy to change,
but I don't think that can be part of the definition.
> Hardware= ware that is hard to change and provide a function only when used
> with some software.
> The soft or hard quality is relative.
A feature could be in hardware or software, if that is what you mean by
relative. I don't really like your definitions however. Hardware is
hard bz you can kick it, not because it is hard to change. But not
everything you can kick is hardware.
Hardware: All components of a computer that can be kicked
Software: All components of a computer that cannot be kicked
??
> For example the mathematics is hardware ;-)
Mathematics is everywhere, in both hardware and software. Cheerss!
--dawn
dawn
Yes.
> What are the basic operations for combining lists and sets ?
The ones that come with any general purpose programming language.
>
> Where do we stop ?
I'm good with programming languages as a "stopping point" building up
from there to higher levels with libraries of code.
> Why not asking for a model to support all mathematics ?
Again, I'm good with programming languages and libraries thereof.
smiles. --dawn
x
> Yes.
OK.
> > What are the basic operations for combining lists and sets ?
> The ones that come with any general purpose programming language.
Can you make a list or a set with them and post it ?
> >
> > Where do we stop ?
> I'm good with programming languages as a "stopping point" building up
> from there to higher levels with libraries of code.
Well, the programmig languages are many. :-)
What programming languages are you refering to ?
The future ones ?
> > Why not asking for a model to support all mathematics ?
> Again, I'm good with programming languages and libraries thereof.
A variable SET of variable LISTs of symbols and a variable SET of variable
LISTs of substitution rules LISTed in some order is what you propose ?
Or the other way around ?
Can you make such a thing declarative (specifying the data, not the process
of getting the data) ?
x
> Yes.
OK.
> > What are the basic operations for combining lists and sets ?
> The ones that come with any general purpose programming language.
Can you make a list or a set with them and post it ?
> >
> > Where do we stop ?
> I'm good with programming languages as a "stopping point" building up
> from there to higher levels with libraries of code.
Well, the programmig languages are many. :-)
What programming languages are you refering to ?
The future ones ?
> > Why not asking for a model to support all mathematics ?
> Again, I'm good with programming languages and libraries thereof.
A variable SET of variable LISTs of symbols and a variable SET of variable
x
> A feature could be in hardware or software, if that is what you mean by
> relative. I don't really like your definitions however. Hardware is
> hard bz you can kick it, not because it is hard to change. But not
> everything you can kick is hardware.
Do you think that hammers are hardware ?
Do you think that CD-ROMs are hardware/software ?
The instructions on how to build a chair are software ?
> Mathematics is everywhere, in both hardware and software. Cheerss!
Yes. But can you kick it ? :-)
dawn
That would take a smarter man than I. I'd be fine with the java.lang
libraries. They are well documented. ;-)
>
> > >
> > > Where do we stop ?
>
> > I'm good with programming languages as a "stopping point" building up
> > from there to higher levels with libraries of code.
>
> Well, the programmig languages are many. :-)
> What programming languages are you refering to ?
> The future ones ?
I'm very flexible that way, which means to me that I'm a bit of a
peasant in that regard. I like functional and OO languages, but once
upon a time I adored procedural languages too and can tolerate
declarative languages.
> > > Why not asking for a model to support all mathematics ?
>
> > Again, I'm good with programming languages and libraries thereof.
>
> A variable SET of variable LISTs of symbols and a variable SET of variable
> LISTs of substitution rules LISTed in some order is what you propose ?
> Or the other way around ?
What works for me is what I would call a di-graph of trees (a tree on
each node of the graph). You can see an example of this with html (or
xhtml) pages. You have a DOM tree (web page) on each node of a
di-graph (web). That is, effectively, what Pick is too, although the
tree doesn't go as many levels deep as the DOM.
> Can you make such a thing declarative (specifying the data, not the process
> of getting the data) ?
I can tell that you will love (and perhaps dislike) my next blog.
While I can understand the advantage to an exclusively declarative
language, I like verbs too. In the end, computer software is going to
process data. Making process fixed, but reusable (in the form of DBMS
tools) while the data patterns have to be perhaps overly clever (to
accomodate the declarative language constraints) and be coded fresh
each time, doesn't strike me as particularly fine.
If we had gone another route and made reusable data entities such as
Person, Address, Product, Order, etc building up to vertical industry
models with developers preparing the processes, would our profession
look different? Don't get me wrong, I think declarative languages are
important in the mix and have some benefits, but I am not fixed on that
as the ultimate goal.
--dawn
Gene Wirchenko
[snip]
>A feature could be in hardware or software, if that is what you mean by
>relative. I don't really like your definitions however. Hardware is
>hard bz you can kick it, not because it is hard to change. But not
>everything you can kick is hardware.
>
>Hardware: All components of a computer that can be kicked
>Software: All components of a computer that cannot be kicked
I like Stan Kelly-Bootle's definition of "module": a part of the
system that can fall off during shipment. Definitely a hardware bias
though.
Sincerely,
Gene wirchenko
dawn
No. The part of a computer that you can kick might be called hardware,
however.
> Do you think that CD-ROMs are hardware/software ?
That is where I don't know how to clearly define the difference. Is an
mp3 on a CD ROM software? If we want to split off data from software,
then it is data, but useless without something that translates the data
to music, for example.
> The instructions on how to build a chair are software ?
Not if they are not part of a computer. Even then, I guess they are
data, but worthless unless someone can use them.
>
> > Mathematics is everywhere, in both hardware and software. Cheerss!
> Yes. But can you kick it ? :-)
No. It is used as a model, a metaphor. So, what are your precise
definitions for hardware and software -- the ones you gave earlier or
do you want to revise? --dawn
mAsterdam
> x wrote:
[snip]
>>Do you think that CD-ROMs are hardware/software ?
>
> That is where I don't know how to clearly define the difference. Is an
> mp3 on a CD ROM software? If we want to split off data from software,
> then it is data, but useless without something that translates the data
> to music, for example.
I may have 2 eurocents to throw in.
You can kick the CD, so that's hardware.
The layout and depth of the physical tracks
is standardized so strictly that if a CD-ROM
reader/writer doesn't comply your recordings
are completely worthless on other reader/writers. Firmware.
The filesystem is pretty much standardized - slight
incompatabilities do occur, though. Though it can be faked
on other media, the filesystem was designed for CDs.
Firmware, but less firm.
The mp3 format can and does occur on any other type of
filesystem, so pure software.
What of the mp3 is data? Not the algorithm to pull the signal
out of it - that's software.
The interpreted signal (a sequence of relative amplitudes) - however
distorted - is data, as are the compression ratio, the duration
of the tracks at normal speed playback and some information
about the recording.
>>The instructions on how to build a chair are software ?
When it is in a form suitable for CAM it is.
x
> No. It is used as a model, a metaphor. So, what are your precise
> definitions for hardware and software -- the ones you gave earlier or
> do you want to revise? --dawn
Any computer can be divided in two disjoint parts: the hardware and the
software.
The software is the part that can be easily changed to modify the function
of a computer.
x
The software is the remainder.
x
> x wrote:
> > "dawn" <dawnwo...@gmail.com> wrote in message
> > news:1138627814.4...@g14g2000cwa.googlegroups.com...
> > > > What are the basic operations for combining lists and sets ?
> >
> > > The ones that come with any general purpose programming language.
> > Can you make a list or a set with them and post it ?
> That would take a smarter man than I. I'd be fine with the java.lang
> libraries. They are well documented. ;-)
I don't use java but I'll look.
Are you talking about abstract collections ?
http://webkemper1.informatik.tu-muenchen.de:8080/interna/oracle10g/doc/appdev.101/b10799/adobjcol.htm
http://www.stanford.edu/dept/itss/docs/oracle/10g/appdev.101/b10807/05_colls.htm
http://www.lc.leidenuniv.nl/awcourse/oracle/appdev.920/a96595/dci01wht.htm
You might want to look at
http://gadfly.sourceforge.net/gadfly.html#architecture
> >
> > > >
> > > > Where do we stop ?
> >
> > > I'm good with programming languages as a "stopping point" building up
> > > from there to higher levels with libraries of code.
> >
> > Well, the programmig languages are many. :-)
> > What programming languages are you refering to ?
> > The future ones ?
> I'm very flexible that way, which means to me that I'm a bit of a
> peasant in that regard. I like functional and OO languages, but once
> upon a time I adored procedural languages too and can tolerate
> declarative languages.
All these languages you talk about use the same model of data ?
> > > > Why not asking for a model to support all mathematics ?
> >
> > > Again, I'm good with programming languages and libraries thereof.
> >
> > A variable SET of variable LISTs of symbols and a variable SET of
variable
> > LISTs of substitution rules LISTed in some order is what you propose ?
> > Or the other way around ?
> What works for me is what I would call a di-graph of trees (a tree on
> each node of the graph). You can see an example of this with html (or
> xhtml) pages. You have a DOM tree (web page) on each node of a
> di-graph (web). That is, effectively, what Pick is too, although the
> tree doesn't go as many levels deep as the DOM.
I didn't know this is what Pick is.
What are the operators that Pick provides for this model ?
Why not a di-graph of di-graphs ?
> > Can you make such a thing declarative (specifying the data, not the
process
> > of getting the data) ?
> I can tell that you will love (and perhaps dislike) my next blog.
I can do both and vice versa at the same time.
> While I can understand the advantage to an exclusively declarative
> language, I like verbs too. In the end, computer software is going to
> process data. Making process fixed, but reusable (in the form of DBMS
> tools) while the data patterns have to be perhaps overly clever (to
> accomodate the declarative language constraints) and be coded fresh
> each time, doesn't strike me as particularly fine.
> If we had gone another route and made reusable data entities such as
> Person, Address, Product, Order, etc building up to vertical industry
> models with developers preparing the processes, would our profession
> look different? Don't get me wrong, I think declarative languages are
> important in the mix and have some benefits, but I am not fixed on that
> as the ultimate goal.
Do you have something similar to this in mind ?
http://www.stanford.edu/dept/itss/docs/oracle/10g/appdev.101/b10807/12_tune.htm#i52954
You might want to look at
https://dpt-info.u-strasbg.fr/doc/oracle/appdev.102/b14288/exprn_expconcepts.htm
http://htmldb.oracle.com/i/doc/intro.htm
x
> > > > What are the basic operations for combining lists and sets ?
> >
> > > The ones that come with any general purpose programming language.
> > Can you make a list or a set with them and post it ?
>
> That would take a smarter man than I. I'd be fine with the java.lang
> libraries. They are well documented. ;-)
In java.lang only some base types for the language are defined.
There is no set or set operators.
Gene Wirchenko
"easily" does not begin to address the essence of the difference.
How many people do you know who can install a motherboard? Be
sure to count all the people at the local computer/electronics stores.
How many people do you know who write an accounting app? To be
fair, be sure to count all the people at the local
computer/electronics stores. What do you mean you only found one?
By that, hardware is software, and software is hardware.
Sincerely,
Gene Wirchenko
dawn
x wrote:
> The hardware is the material part of a computer.
> The software is the remainder.
I'm good with that, but then you get back to the question of software
developers being those who develop the software and by this definition
that would include those who do "data entry" because data and software
are together in your definition. Again, I think of data and software
together, but I do not think of software developers and end-users of
software as being one and the same. So, I'm stumped (at least
temporarily) on the definition of software as in the phrase "software
developer." --dawn
dawn
> "dawn" <dawnwo...@gmail.com> wrote in message
> news:1138642417.4...@o13g2000cwo.googlegroups.com...
> > x wrote:
> > > "dawn" <dawnwo...@gmail.com> wrote in message
> > > news:1138627814.4...@g14g2000cwa.googlegroups.com...
>
> > > > > What are the basic operations for combining lists and sets ?
> > >
> > > > The ones that come with any general purpose programming language.
> > > Can you make a list or a set with them and post it ?
>
> > That would take a smarter man than I. I'd be fine with the java.lang
> > libraries. They are well documented. ;-)
>
> I don't use java but I'll look.
> Are you talking about abstract collections ?
Yes. I wouldn't say that the collections framework is necessarily
ideal, but it works. Not being someone who writes languages, I would
say that the operations you are asking about are compositions of
functions. Of course lists are maps (functions) which are sets.
Perhaps I could answer a question about "how do you do this?" better
than a general question about what the operators are (but maybe not).
> http://webkemper1.informatik.tu-muenchen.de:8080/interna/oracle10g/doc/appdev.101/b10799/adobjcol.htm
> http://www.stanford.edu/dept/itss/docs/oracle/10g/appdev.101/b10807/05_colls.htm
>
> http://www.lc.leidenuniv.nl/awcourse/oracle/appdev.920/a96595/dci01wht.htm
>
> You might want to look at
> http://gadfly.sourceforge.net/gadfly.html#architecture
Interesting. I had never heard of cylindric logic before. I didn't
look into it (yet).
> > >
> > > > >
> > > > > Where do we stop ?
> > >
> > > > I'm good with programming languages as a "stopping point" building up
> > > > from there to higher levels with libraries of code.
> > >
> > > Well, the programmig languages are many. :-)
> > > What programming languages are you refering to ?
> > > The future ones ?
>
> > I'm very flexible that way, which means to me that I'm a bit of a
> > peasant in that regard. I like functional and OO languages, but once
> > upon a time I adored procedural languages too and can tolerate
> > declarative languages.
>
> All these languages you talk about use the same model of data ?
No, but every general purpose language I have seen permits use of a
logical model of data that includes attributes with values that are
lists.
> > > > > Why not asking for a model to support all mathematics ?
> > >
> > > > Again, I'm good with programming languages and libraries thereof.
> > >
> > > A variable SET of variable LISTs of symbols and a variable SET of
> variable
> > > LISTs of substitution rules LISTed in some order is what you propose ?
> > > Or the other way around ?
>
> > What works for me is what I would call a di-graph of trees (a tree on
> > each node of the graph). You can see an example of this with html (or
> > xhtml) pages. You have a DOM tree (web page) on each node of a
> > di-graph (web). That is, effectively, what Pick is too, although the
> > tree doesn't go as many levels deep as the DOM.
>
> I didn't know this is what Pick is.
> What are the operators that Pick provides for this model ?
I'll have to learn how to think in those terms. One language provided
with every Pick implementation is a version of BASIC called DataBASIC.
You can see what operators are included in this at
But other languages can be used too (in client/server mode)
> Why not a di-graph of di-graphs ?
I don't have a good answer for why the web, a di-graph of trees, is so
successful. I have ideas about it relating to language. If you think
of a single proposition, you can model it with a tree (not unlike
diagramming sentences as we did at my grade school). Then the
relationship between propositions gives us a di-graph.
> > > Can you make such a thing declarative (specifying the data, not the
> process
> > > of getting the data) ?
>
> > I can tell that you will love (and perhaps dislike) my next blog.
>
> I can do both and vice versa at the same time.
It's posted http://www.tincat-group.com/mewsings
> > While I can understand the advantage to an exclusively declarative
> > language, I like verbs too. In the end, computer software is going to
> > process data. Making process fixed, but reusable (in the form of DBMS
> > tools) while the data patterns have to be perhaps overly clever (to
> > accomodate the declarative language constraints) and be coded fresh
> > each time, doesn't strike me as particularly fine.
>
> > If we had gone another route and made reusable data entities such as
> > Person, Address, Product, Order, etc building up to vertical industry
> > models with developers preparing the processes, would our profession
> > look different? Don't get me wrong, I think declarative languages are
> > important in the mix and have some benefits, but I am not fixed on that
> > as the ultimate goal.
>
> Do you have something similar to this in mind ?
> http://www.stanford.edu/dept/itss/docs/oracle/10g/appdev.101/b10807/12_tune.htm#i52954
I don't think that is what I was talking about in this paragraph, but
yes, this has similarities to the trees-in-a-di-graph approach. In
this case, the di-graph is made up of relations with foreign keys and
the trees are in clobs. In the MV products you can store XML within
the structure (not in clobs) if they are not too deep and then query
them with the standard query language.
>
>
> You might want to look at
> https://dpt-info.u-strasbg.fr/doc/oracle/appdev.102/b14288/exprn_expconcepts.htm
> http://htmldb.oracle.com/i/doc/intro.htm
Definitely interesting. I hadn't look at Oracle HTML DB before. By
the way, x, do you happen to work for Oracle? --dawn
x
> By the way, x, do you happen to work for Oracle?
No. Sorry if it looked like an ad.
I am not the employee of any software/hardware company and I don't own
shares at any software/hardware company.
x
>By the way, x, do you happen to work for Oracle? --dawn
x
"Gene Wirchenko" <ge...@ucantrade.com.NOTHERE> wrote in message
news:l36vt1h9cvq3n3rfi...@4ax.com...
> On Tue, 31 Jan 2006 09:53:04 +0200, "x" <x...@not-exists.org> wrote:
>
> >"dawn" <dawnwo...@gmail.com> wrote in message
> >news:1138652402.4...@g47g2000cwa.googlegroups.com...
>
> >> No. It is used as a model, a metaphor. So, what are your precise
> >> definitions for hardware and software -- the ones you gave earlier or
> >> do you want to revise? --dawn
> >
> >Any computer can be divided in two disjoint parts: the hardware and the
> >software.
> >The software is the part that can be easily changed to modify the
function
> >of a computer.
>
> "easily" does not begin to address the essence of the difference.
>
> How many people do you know who can install a motherboard? Be
> sure to count all the people at the local computer/electronics stores.
How many people do you know who can manufacture a motherboard (including the
microprocessor) ?
Be sure to count all the people at the local computer/electronics stores.
How many people do you know who can alter the chips on the motherboard after
that ?
Be sure to count all the people at the local computer/electronics stores.
> How many people do you know who write an accounting app? To be
> fair, be sure to count all the people at the local
> computer/electronics stores. What do you mean you only found one?
> By that, hardware is software, and software is hardware.
Yes. Isn't it ? :-)
x
Data entry is the same as data development ?
JOG
That sounds nonsensical to my ears - one cannot 'develop' data, just as
one can't 'develop' a one or a zero.
dawn
Agreed. One can implement systems in a combination of software and
hardware. But if h/w is what you can weigh (or kick or ...) in a
computer and s/w is the rest, then what is a s/w developer? If it is
anyone participating in creating software and the software is
everything you cannot kick, then a data entry person would be a
software developer. That doesn't work for me, so help me out. What is
software as in "software developer"? It was clear to me for a brief
second and escaped me when trying to capture the thought in words.
Thanks. --dawn
x
"JOG" <j...@cs.nott.ac.uk> wrote in message
news:1138804160.3...@g44g2000cwa.googlegroups.com...
So there is a clear distinction between data entry and software
development.
x
No because entry is not developing :-)
The one that do software entry are called software developers ?
To distinguish data from software you can say that the software provide a
function and data does not. The data is processed.
dawn
The software might just be sitting there, processing nothing at any
given point. Is it then data and NOT software? Derived data would
certainly then be software. What data is not derived from bytes? There
is nothing without functions except an unaccessed disk.
--dawn
JOG
originally referred to the part of the pc that wasn't hardware, however
this has evolved over the last half century, and software now generally
denotes encoded machine instructions for the hardware to execute. If it
isn't designed to be executed it's just common garden data.
Bill Cooke
Many many years ago i wrote a short piece titled something like "what
does a programmer do?" (I was one, and had difficulties in bars
explaining myself, and figured all Datamation readers had the same
problem.). At the bottom of the page was a line something like "a
programmer describes a procedure, in enough detail to be performed by a
computer, to another programmer."
The forty year update? A software developer is one who writes to
another software developer stuff that could be performed by a computer.
And it might appear in a form (hardware) which a computer can read. The
stuff is software.
Why is this important? It's like: what's an oil painting?
x
>
> x wrote:
> > No because entry is not developing :-)
> > The one that do software entry are called software developers ?
> >
> > To distinguish data from software you can say that the software provide
a
> > function and data does not. The data is processed.
> The software might just be sitting there, processing nothing at any
> given point. Is it then data and NOT software?
It is both software and data.
> Derived data would
> certainly then be software. What data is not derived from bytes? There
> is nothing without functions except an unaccessed disk.
What kind of function ?
The point is that software is the part that is usually replaced/altered for
changing the function of the whole system.
Think about those old computers programable by changing the wiring.
The wires are hardware, but the wiring scheme is software.
When you store this wiring scheme in the computer, it is data.
Do you consider the UML diagram is software ?
dawn
x wrote:
> "dawn" <dawnwo...@gmail.com> wrote in message
> news:1138810467.8...@z14g2000cwz.googlegroups.com...
> >
> > x wrote:
>
> > > No because entry is not developing :-)
> > > The one that do software entry are called software developers ?
> > >
> > > To distinguish data from software you can say that the software provide
> a
> > > function and data does not. The data is processed.
>
> > The software might just be sitting there, processing nothing at any
> > given point. Is it then data and NOT software?
>
> It is both software and data.
>
>
> > Derived data would
> > certainly then be software. What data is not derived from bytes? There
> > is nothing without functions except an unaccessed disk.
>
> What kind of function ?
> The point is that software is the part that is usually replaced/altered for
> changing the function of the whole system.
>
> Think about those old computers programable by changing the wiring.
> The wires are hardware, but the wiring scheme is software.
Ah, now that is a different spin on it. How would you license and
deliver this software?
> When you store this wiring scheme in the computer, it is data.
>
> Do you consider the UML diagram is software ?
No. If it is part of a round-trip with a programming language, then it
is a representation of the software just as the source code is.
Otherwise it might be part of the design documents or specification of
the software. I still don't have a def of s/w that I like, however.
--dawn
x
>
> x wrote:
> > What kind of function ?
> > The point is that software is the part that is usually replaced/altered
for
> > changing the function of the whole system.
> >
> > Think about those old computers programable by changing the wiring.
> > The wires are hardware, but the wiring scheme is software.
> Ah, now that is a different spin on it. How would you license and
> deliver this software?
I don't know. I'm not in the business of selling software and I'm not an
attorney.
The same as poetry I guess.
Mine usually come over the Internet or on CDs these days and is mostly free.
> > When you store this wiring scheme in the computer, it is data.
> > Do you consider the UML diagram is software ?
> No. If it is part of a round-trip with a programming language, then it
> is a representation of the software just as the source code is.
> Otherwise it might be part of the design documents or specification of
> the software. I still don't have a def of s/w that I like, however.
Maybe there is a legal definition of software somewhere.
Marshall Spight
> x wrote:
> >
> > > > What are the basic operations for combining lists and sets ?
> >
> > > The ones that come with any general purpose programming language.
> > Can you make a list or a set with them and post it ?
>
> That would take a smarter man than I. I'd be fine with the java.lang
> libraries. They are well documented. ;-)
(You probably meant java.util; specifically the "Collections API.")
The collections API is quite an achievement, and is IMHO a significant
contributor to Java's overall success. But it doesn't qualify
as a foundational set of operations. It's goal is maximal inclusiveness
and convenience; not minimal completeness.
I think a good case can be made for the basic operations on set
being the union, intersection, difference; for relations being the
relational algebra, and for lists being simply car, cdr, cons.
How you would combine operations on lists and sets is an
open question in my mind. Can natural join be applied to
a pair of lists?
> > Why not asking for a model to support all mathematics ?
>
> Again, I'm good with programming languages and libraries thereof.
Ha! How are these different? Riddle: I want a way to express
all computable functions. Am I a mathematician or a programmer?
Marshall
Marshall Spight
>
> > My beef with the RM is related both to normalization theory as taught
> > in colleges and universities, discussed in the Is Codd Dead? blog
> > and to the way the RM, or parts thereof, are used in the practice of
> > software development and maintenance today. It shapes the thinking of
> > software developers in ways that are often not the most effective.
>
> I have really no idea where this comes from. When I teach normalization
> I do that in the context of the relational model.
My general sense is that when Dawn is criticising normalization she
means specifically 1NF. I don't think she has any beef with, say,
BCNF. I could be wrong.
Marshall
Marshall Spight
>
> I don't know who told you that lists are somehow only representation
> while sets are not, but that is nonsense.
I seem to remember a prominent troll from a few years ago who insisted
that the only order that existed was logical order on the members of a
set, and that anything else was necessarily implementational and had
no value. I agree that this is nonsense.
> The reason to avoid lists is
> far more mundane and practical; it would make the DBMS more complex and
> make tasks such as query optimization, concurrency control and integrity
> maintenance harder. It would also make the theory more complex, which in
> the long term usually also translates into practical problems.
And yet.
While your concerns are of course good ones, I still stongly feel that
the lists-or-sets-but-not-both rut that the field has gotten into is
not
only a false dichotomy but a pernicious one. As a programmer, I want
both! I *insist* on both, and I don't want one implemented on top of
the other. Nor do I want my collection handling relegated to libraries;
collections are too fundamental not to be a direct part of the
language.
To me, SQL and the APL family are demonstrations of this. Death
to the for loop!
> Sure, bathing regularly is also not necessary. It's still a good idea
> though. :-)
On this point we agree. :-)
Marshall
PS. Or as is sometimes said, "we are in agreeance."
Marshall Spight
>
> I agree (I guess it makes sense that I would agree with you agreeing
> with me). While ordering functions (SORT) may be defined on sets,
> those are orderings on values. There is no ordering within the
> relational structure itself.
Sometimes order may be abstracted away, but sometimes it may not.
I could give you a list of my children in birth order including their
birthdates,
and the order information would be redundant. I can give you a list of
the statements that make up my java method, and if you execute the
instructions in arbitrary order, you've changed the definition. If you
want to put BASIC-style line numbers in there, I'd call that a 30
year regression.
Marshall
JOG
they do serve to remind that anyone who deals with the theoretical end
of things must always be aware that they are simply using theory to
create something useful to people in practice. As such, must always
listen to what people need and want. And Marshall is correct that order
is damn important in practice. How many database driven don't use the
sort command to create an ordered set?
Marshall Spight wrote:
> I think a good case can be made for the basic operations on set
> being the union, intersection, difference; for relations being the
> relational algebra, and for lists being simply car, cdr, cons.
> How you would combine operations on lists and sets is an
> open question in my mind. Can natural join be applied to
> a pair of lists?
Well in the end a list is just a totally-ordered set of items and as
such there is a whole mathematical field out there in 'order theory'
that might be applied with Codd-esque rigour to create native support
for orderings in a database. But its always important to keep the two
seperate concepts distincts even if you're supporting both.
Two possibilities that I can think of - it might be possible to say
that merging an unordered set and a totally-ordered set (list) might
reasonably create a partially ordered set. (hence you have a general
system that handles all types of ordered sets underneath the hood). Or
you might just want to make everything a list as in the case of lisp
(and who knows, there might be something to be said for that). I think
the former probably has more potential.
Marshall Spight wrote:
> While your concerns are of course good ones, I still stongly feel that
> the lists-or-sets-but-not-both rut that the field has gotten into is
> not only a false dichotomy but a pernicious one.
Totally agree. And in fact by sorting a db-relation you are in essence
creating a list given the order of its delivery back to you now has
implicit meaning. So in a sense practice is already forcing support for
both.
> As a programmer, I want
> both! I *insist* on both, and I don't want one implemented on top of
> the other. Nor do I want my collection handling relegated to libraries;
> collections are too fundamental not to be a direct part of the
> language.
Power to the programmer ;) However as a c++ coder I often don't
distinguish between the libraries and the language. Nowadays the STL
_is_ c++ (and more and more so the 3rd party boost libraries).
Jim.
David Cressey
> Two possibilities that I can think of - it might be possible to say
> that merging an unordered set and a totally-ordered set (list) might
> reasonably create a partially ordered set. (hence you have a general
> system that handles all types of ordered sets underneath the hood). Or
> you might just want to make everything a list as in the case of lisp
> (and who knows, there might be something to be said for that). I think
> the former probably has more potential.
>
When we built Muddle (aka MDL) we implemented arrays and lists for almost
precisely the reason you and Marshall have outlined here. If you have
lists, you need arays for direct access, when things get big. If you have
arrays, you need lists when
splicing in a new item is cheaper than shuffling everything to one side.
So we built both.
"arrays" doesn't really address the same issue as "sets", but there's some
overlap.
I'm talking physical, here.
At the logical level, there isn't that much difference between a list and a
set, is there?
dawn
David Cressey wrote:
> "JOG" <j...@cs.nott.ac.uk> wrote in message
> news:1139107816....@g43g2000cwa.googlegroups.com...
>
> > Two possibilities that I can think of - it might be possible to say
> > that merging an unordered set and a totally-ordered set (list) might
> > reasonably create a partially ordered set. (hence you have a general
> > system that handles all types of ordered sets underneath the hood). Or
> > you might just want to make everything a list as in the case of lisp
> > (and who knows, there might be something to be said for that). I think
> > the former probably has more potential.
> >
>
> When we built Muddle (aka MDL) we implemented arrays and lists for almost
> precisely the reason you and Marshall have outlined here. If you have
> lists, you need arays for direct access, when things get big. If you have
> arrays, you need lists when
> splicing in a new item is cheaper than shuffling everything to one side.
>
> So we built both.
Just so I understand precisely, what is the user interface in working
with arrays compared to lists? With these lists are you unable to
directly access the n'th entry in the list (list[n], for example)?
>
> "arrays" doesn't really address the same issue as "sets", but there's some
> overlap.
> I'm talking physical, here.
>
> At the logical level, there isn't that much difference between a list and a
> set, is there?
At the logical level, I don't know the difference between a list and
array, but a set does not have the ordering that a list has. If you
ask for all e-mail addresses when they are in a list, you get them in
the order of the list. If you ask for them when logically in a set,
the ordering in the response has no logical meaning.
--dawn
dawn
Marshall Spight wrote:
> dawn wrote:
> > x wrote:
> > >
> > > > > What are the basic operations for combining lists and sets ?
> > >
> > > > The ones that come with any general purpose programming language.
> > > Can you make a list or a set with them and post it ?
> >
> > That would take a smarter man than I. I'd be fine with the java.lang
> > libraries. They are well documented. ;-)
>
> (You probably meant java.util; specifically the "Collections API.")
My thinking was muddled right then, I suspect, but I started with the
collections api and did have java.util but before sending it figured I
only needed the basic language and could build up from there. But,
yes, I was initially thinking of the collections api.
>
> The collections API is quite an achievement, and is IMHO a significant
> contributor to Java's overall success. But it doesn't qualify
> as a foundational set of operations. It's goal is maximal inclusiveness
> and convenience; not minimal completeness.
Yes, it is very useful. Someone once mentioned that it does not have
relations. However, with maps, which are functions, you could
implement any relation that is a function (any with a primary key). It
just doesn't have the same operations on that map as on relations in an
rdbms.
> I think a good case can be made for the basic operations on set
> being the union, intersection, difference; for relations being the
> relational algebra, and for lists being simply car, cdr, cons.
> How you would combine operations on lists and sets is an
> open question in my mind. Can natural join be applied to
> a pair of lists?
>
>
> > > Why not asking for a model to support all mathematics ?
> >
> > Again, I'm good with programming languages and libraries thereof.
>
> Ha! How are these different?
That was somewhat my point. It is the RM that insists on restricting
the mathematics to some castrated subset of mathematics that causes
problems for the user, methinks.
> Riddle: I want a way to express
> all computable functions. Am I a mathematician or a programmer?
Yes. smiles. --dawn
>
> Marshall
David Cressey
"dawn" <dawnwo...@gmail.com> wrote
> >
> > When we built Muddle (aka MDL) we implemented arrays and lists for
almost
> > precisely the reason you and Marshall have outlined here. If you have
> > lists, you need arays for direct access, when things get big. If you
have
> > arrays, you need lists when
> > splicing in a new item is cheaper than shuffling everything to one side.
> >
> > So we built both.
>
> Just so I understand precisely, what is the user interface in working
> with arrays compared to lists? With these lists are you unable to
> directly access the n'th entry in the list (list[n], for example)?
>
Oops, my bad. I was thinking here of "lists" as used in lisp, not as
probably intended in this discussion. The mention of "car", "cdr", and
"cons" elsewhere in the discussion put me in the lisp context.
x
>
> x wrote:
> >
> > Think about those old computers programable by changing the wiring.
> > The wires are hardware, but the wiring scheme is software.
>
> Ah, now that is a different spin on it. How would you license and
> deliver this software?
Have you noticed that software is always marked as such ?
I wonder why.
x
> > > > Why not asking for a model to support all mathematics ?
> > >
> > > Again, I'm good with programming languages and libraries thereof.
> >
> > Ha! How are these different?
>
> That was somewhat my point. It is the RM that insists on restricting
> the mathematics to some castrated subset of mathematics that causes
> problems for the user, methinks.
It would be very nice to have all mathematics computerized.
David Cressey
"x" <x...@not-exists.org> wrote
> It would be very nice to have all mathematics computerized.
It would be even nicer to have all computerization mathematical.
x
"David Cressey" <dcre...@verizon.net> wrote in message
news:CxHFf.3017$_I4.1863@trndny02...
> It would be even nicer to have all computerization mathematical.
But how can we tell when we have achieved that without a definition of
Mathematics ? ;-)
JOG
[snip]
> When we built Muddle (aka MDL) we implemented arrays and lists for almost
> precisely the reason you and Marshall have outlined here. If you have
> lists, you need arays for direct access, when things get big. If you have
> arrays, you need lists when
> splicing in a new item is cheaper than shuffling everything to one side.
>
> So we built both.
>
> "arrays" doesn't really address the same issue as "sets", but there's some
> overlap.
> I'm talking physical, here.
>
> At the logical level, there isn't that much difference between a list and a
> set, is there?
Aye, given a list is just a set with a binary ordering applied to it, a
user can quite happily just ignore that ordering to be left with the
set concept, so shifting the cognitive load of interpretation onto
them. About a year ago I was working on a hugely ambitious product with
a hypertext luminary, that consisted solely of intercrossing lists of
content nodes (like a multi-dimensional spreadsheet in some ways). The
main engineering problem was accessing different parts (mainly the
head) of one of these list ranks in O(1) as opposed to O(n) linked list
traversal, but there also existed the issue of how a set of items be
denoted in a system that consisted solely of lists.This proved far more
of a minefield than it initially seemed in terms of the manipulation
language.
Ultimately, one of the conclusions I drew from that project are that
sets and lists are both vital to the user's information needs, but that
the two concepts should be kept distinct. I am yet to resolve the
impact this has for closure on any algebra applied to them.
So your description of MDL seems to strike a chord - and I'm interested
to know what the design principles behind it were and ultimately what
happened to it? I understand that it was a post-Lisp implemenation, but
Wikipedia unfortunately only holds a stub (David - you should add a bit
to this being a man in the know).
All best, Jim.
x
with at least two collections as parameters or any method that take two
collection and return one from them. All I have seen are methods for working
on collections with one element at the time, for sorting , for conversion,
equality and inclusion testing and this wonderful piece of work:
http://java.sun.com/j2se/1.4.2/docs/guide/collections/designfaq.html#14
http://java.sun.com/j2se/1.4.2/docs/guide/collections/designfaq.html#6
David Cressey
"JOG" <j...@cs.nott.ac.uk> wrote
> So your description of MDL seems to strike a chord - and I'm interested
> to know what the design principles behind it were and ultimately what
> happened to it? I understand that it was a post-Lisp implemenation, but
> Wikipedia unfortunately only holds a stub (David - you should add a bit
> to this being a man in the know).
I'll start another discussion. Unfortunately, it seem pretty far afield of
comp.databases.theory, but so be it.
Jan Hidders
> Jan Hidders wrote:
>
>>dawn schreef:
>>
>>>Jan Hidders wrote:
>>>>
>>>>The reason to avoid lists is
>>>>far more mundane and practical; it would make the DBMS more complex and
>>>>make tasks such as query optimization, concurrency control and integrity
>>>>maintenance harder.
>>>
>>
>>The implementors of the DBMS.
>
> BINGO! Having been on the applications side of the house, I am aware
> that choices are made on user interface design decisions are sometimes
> made due to the cost of implementation or support for the developers.
> But for an entire industry to fix on that strategy when the user is a
> programmer is really dreadful. It seems someone could look at how to
> make the end-user (in this case a software developer) as productive as
> possible.
That is what has been looked at, and the claim of the relational model
is that in the cases where data independence, concurrency control and
integrity maintenance are important it indeed does that.
>>PS. I'm really signing off now as my train leaves within a few hours.
>>Expect a reply after a week or so.
>
> Have a good trip. (Or, rather, I hope you had a good trip and enjoyed
> your time away from the screen and keyboard.)
Thanks. :-)
-- Jan Hidders
Jan Hidders
>
> While your concerns are of course good ones, I still stongly feel that
> the lists-or-sets-but-not-both rut that the field has gotten into is
> not
> only a false dichotomy but a pernicious one.
Did you read the XIME-P call for papers? Now try and guess on which side
of the dichotomy I am sitting. :-)
-- Jan Hidders
dawn
I'd be happy for you to spell it out, Jan. You are pro-RM and
pro-XQuery, is that right? Sorry I haven't quite figured it out yet.
Since this topic is still going, I'll mention that I just posted my
most recent blog entry. This one has more meat than the last. My
intent was to write this one in such a way that it would be considered
accurate by all (or at least almost all) parties, even if a topic not
all parties would discuss.
Cheers! --dawn
Blog: www.tincat-group.com/mewsings
Jan Hidders
> Jan Hidders wrote:
>
>>Marshall Spight wrote:
>>
>>>While your concerns are of course good ones, I still stongly feel that
>>>the lists-or-sets-but-not-both rut that the field has gotten into is
>>>not
>>>only a false dichotomy but a pernicious one.
>>
>>Did you read the XIME-P call for papers? Now try and guess on which side
>>of the dichotomy I am sitting. :-)
>
> I'd be happy for you to spell it out, Jan. You are pro-RM and
> pro-XQuery, is that right?
And pro-Pick, if that happens to be the best tool for the job at hand. ;-)
-- Jan Hidders
dawn
And a politician too. A question, then, is when you think a non-RM
model would be advisable. --dawn
Marshall Spight
Uh, well I knew you had a strong interest in XQuery. But I guess I
don't
entirely understand your last comment; perhaps because I don't
know much about XQuery. It seems like, being XML based, it wouldn't
be altogether clear on how it feels about types and order and so forth.
Marshall
David Cressey
"dawn" <dawnwo...@gmail.com> wrote in message
> And a politician too. A question, then, is when you think a non-RM
> model would be advisable. --dawn
Whenever some other model is more advisable for the task at hand.
When is it a good idea to go somewhere other than London?
Marshall Spight
>
> When is it a good idea to go somewhere other than London?
When you're feeling like seeing something besides Kensington Garden?
Marshall
JOG
David Cressey wrote:
[snip]
> Whenever some other model is more advisable for the task at hand.
>
> When is it a good idea to go somewhere other than London?
always?
Jan Hidders
> Jan Hidders wrote:
>
>>dawn wrote:
>>
>>>I'd be happy for you to spell it out, Jan. You are pro-RM and
>>>pro-XQuery, is that right?
>>
>>And pro-Pick, if that happens to be the best tool for the job at hand. ;-)
>
> And a politician too. A question, then, is when you think a non-RM
> model would be advisable.
That question is way to broad and over-simplifying so I cannot give a
clear and meaningful anser to that. It's like asking 'when would you not
use a hammer?'. Are we talking about about the RM as a data-model per
se? Or as a data model at the external level of a DBMS? Or at the
logical level of a DBMS? Are we talking about existing DBMSs or
hypothetical ones? These are all different questions with different
complex answers.
-- Jan Hidders
Jan Hidders
>
> Uh, well I knew you had a strong interest in XQuery. But I guess I
> don't entirely understand your last comment; perhaps because I don't
> know much about XQuery. It seems like, being XML based, it wouldn't
> be altogether clear on how it feels about types and order and so
> forth.
It's extremely clear on that. XML is an ordered data model so XQuery
deals with that extensively. XML has an elaborate typing theory
associated with it (see XML Schema) and XQuery allows you to use that if
you so desire.
-- Jan Hidders
dawn
OK, I'll take a quick stab at a clearer question. If you were writing
a "data processing 101" type of application, such as a "Pet Store" app
(if you are familiar with the Java and other Pet Store examples) or the
Joke Response System described on my web site
http://www.tincat-group.com/swdev/jokesreq.html and you had complete
freedom in tool and standards selections, would you be more likely to
choose a Relational Model to work with your DBMS or an "XML data model"
or other model that includes attributes with list values?
Additionally, if you chose a SQL-DBMS tool for practical purposes such
as wide-spread use and availability, is there something lacking from
current tools that use alternative data models (e.g. XML database,
Cache', PICK databases such as IBM U2, Berkeley-DB,...) that would
cause you to reconsider if such features magically appeared?
Thanks! --dawn
Marshall Spight
I thought I remembered you saying to me once that attributes were
unordered and element were ordered. (Or was it the other way around?)
But that confuses me; since elements can be nested but attributes
can't,
this seems to say that you can have nested ordered data but not
nested unordered data. Why? One sign of good design I look for
is orthogonality. Anyway I still haven't heard any clear indication of
when or why one would use elements vs. attributes. They seem
to have substantial overlap.
Is XML Schema supposed to replace DTDs? The idea of the
type system and schema being separate and optional relative
to the data format is incomprehensible; I cannot distinguish between
an optional type system and no type system.
(The FP community has as meme that says that retrofitting a
type system onto a programming language is hard, bordering
on doomed; that would seem to apply here.)
I am still at a loss to explain the attraction of XML-family standards
to impressive people such as yourself and Philip Wadler. My only
working hypothesis is that it's the same reason that Sherlock
Holmes took cocaine. Even thought it's really unhealthy, there's
just not enough going on to keep the powerful mind occupied
otherwise. I note that Wadler has done a lot with XML but
still says "The problem that it solves isn't very hard, and it
doesn't solve it very well." This would seem to fit my working
hypothesis.
But I still wonder what all the fuss is about, and can't help
but feel that my strong negative aesthetic reaction to XML
is keeping me from seeing something otherwise valuable.
I would certainly love to see a set, or even one, of an
example of something short but impressive one can do
with XML, so that I can be impressed the way I was impressed
the first time I was when someone showed me a many-to-many
association.
Marshall
Mikito Harakiri
> I am still at a loss to explain the attraction of XML-family standards
> to impressive people such as yourself and Philip Wadler.
... Abiteboul, Vianu, Libkin and countless outhers. Perhaps they never
got their hands dirty in the field? Say writing a client which is
supposed to query payroll data from enterprise system. Naturally,
enterprise systems these days don't provide you connection which you
just could run SQL query over. Their "progressive" design pushes XML
formatted data to the client. I don't think anybody who dealt with XML
based solutions for enterprise application integration would develop
anything different from Pascal-like attitude towards XML.
JOG
for projects related to it, and gradually but inevitably impressive
people become involved. They establish entrenched research interests,
and the cycle self-perpetuates until something more fashionable
arrives. Someone should coin the definition of IT evolution as
"survival of the trendiest".
x
It is like the emperor's new clothes.
dawn
I've used that phrase for 1NF before, but, of course, it is just spin.
My take on XML is that it got at least two important things right. 1)
It has a data model that is more useful in that it can be used to model
data for any interface, not just a database interface and 2) it doesn't
have any unvalue values, such as the SQL NULL.
There is plenty I don't like including 1) Performance can still kill a
project and it seems a dog of a format for exchanging data. 2) It
isn't particularly easy to work with in a programming language. It is
much easier it is to manipulate the data with JSON, for example. 3)
the XML schema drives me nuts and I don't even know how to put that
into words. I think Marshall got at one side where you can think of it
as untyped without enforcing a schema, but if you wanted to enforce a
schema it just looks too painful to do so. I suspect some folks have
given up and put constraints and validations in code instead.
But as long as I think of it as an upgrade to csv (comma-quote) format
for data exchange, or a way to model data for a query language that is
not as restrictive as SQL, it works for me. Cheers! --dawn
P.S. This is still in my blatant ad (for www.tincat-group.com/mewsings
in case I didn't mention that ;-) thread and perhaps should move?
Jan Hidders
>
> [...] If you were writing
> a "data processing 101" type of application, such as a "Pet Store" app
> (if you are familiar with the Java and other Pet Store examples) or the
> Joke Response System described on my web site
> http://www.tincat-group.com/swdev/jokesreq.html and you had complete
> freedom in tool and standards selections, would you be more likely to
> choose a Relational Model to work with your DBMS or an "XML data model"
> or other model that includes attributes with list values?
For the Joke Response System I would choose RM-oriented tools, as I
don't think that the data and the associated access patterns are
evidently hierarchically organized.
> Additionally, if you chose a SQL-DBMS tool for practical purposes such
> as wide-spread use and availability, is there something lacking from
> current tools that use alternative data models (e.g. XML database,
> Cache', PICK databases such as IBM U2, Berkeley-DB,...) that would
> cause you to reconsider if such features magically appeared?
Hmmm, data independence would be an important factor.
-- Jan Hidders
Jan Hidders
>
> I thought I remembered you saying to me once that attributes were
> unordered and element were ordered. (Or was it the other way around?)
No, that is correct.
> But that confuses me; since elements can be nested but attributes
> can't, this seems to say that you can have nested ordered data but
> not nested unordered data. Why?
No no, there is no ordering *between* attributes, i.e., for a 'table'
element the 'width' attribute and 'border' attribute have to particular
order; there is no such thing as the first attribute. But inside the
attribute the data is ordered. All data is ordered.
> One sign of good design I look for is
> orthogonality. Anyway I still haven't heard any clear indication of
> when or why one would use elements vs. attributes. They seem to have
> substantial overlap.
The same holds for attributes and entities in ER models; you can often
choose whether you want to model something as a full-blown entity or
merely as an attribute. Why do you think that is a problem?
> Is XML Schema supposed to replace DTDs?
Yes.
> The idea of the type system
> and schema being separate and optional relative to the data format is
> incomprehensible; I cannot distinguish between an optional type
> system and no type system.
If you think it is important and you are in control of all the data
streams then you can enforce it. If you are not control, then you are
still able to deal with it. It simply gives you more choice.
> (The FP community has as meme that says that retrofitting a type
> system onto a programming language is hard, bordering on doomed; that
> would seem to apply here.)
Are you sure you are not confusing the data model with the language.
XQuery is not the only language for manipulating XML data. XQuery was
from the start designed to be a typed language and typing was certainly
not retro-fitted onto it.
> I am still at a loss to explain the attraction of XML-family
> standards to impressive people such as yourself and Philip Wadler. My
> only working hypothesis is that it's the same reason that Sherlock
> Holmes took cocaine. Even thought it's really unhealthy, there's just
> not enough going on to keep the powerful mind occupied otherwise. I
> note that Wadler has done a lot with XML but still says "The problem
> that it solves isn't very hard, and it doesn't solve it very well."
> This would seem to fit my working hypothesis.
I can only confirm what Phil said, but would add "but it solves them
well enough to be useful" and I am quite sure he agrees with that. It's
a bit like C++, it's often clumsy, unelegant and very baroque, but it
usually does the job and (last but not least) it is a widely accepted
standard. The importance of this final point is easily underestimated.
-- Jan Hidders
dawn
Jan Hidders wrote:
> dawn wrote:
> >
> > [...] If you were writing
> > a "data processing 101" type of application, such as a "Pet Store" app
> > (if you are familiar with the Java and other Pet Store examples) or the
> > Joke Response System described on my web site
> > http://www.tincat-group.com/swdev/jokesreq.html and you had complete
> > freedom in tool and standards selections, would you be more likely to
> > choose a Relational Model to work with your DBMS or an "XML data model"
> > or other model that includes attributes with list values?
>
> For the Joke Response System I would choose RM-oriented tools, as I
> don't think that the data and the associated access patterns are
> evidently hierarchically organized.
That's what I suspected. I would use a web-like model with a di-graph
of little trees.
>
> > Additionally, if you chose a SQL-DBMS tool for practical purposes such
> > as wide-spread use and availability, is there something lacking from
> > current tools that use alternative data models (e.g. XML database,
> > Cache', PICK databases such as IBM U2, Berkeley-DB,...) that would
> > cause you to reconsider if such features magically appeared?
>
> Hmmm, data independence would be an important factor.
I'd like to better understand data independence in terms of
functionality.
Does it mean that if a new version of a DBMS tool takes the same
logical specification it can lay the bytes down differently on the disk
without application code changing? In that case, I'm pretty sure most
DBMS tools, including MUMPS and PICK, fit the bill.
Or does the decoupling of physical and logical mean that if I want to
store attribute data physically "along with" a different entity (table)
than where it is now (and rework the logical model), no application
software needs to change? Using a SQL-DBMS, that would mean no data
should be accessed through a base table, only through derived views.
In that case, no dbms enforces such and I don't know if there are
software applications that function that way.
I'm likely confused on this topic as I have not studied it in depth.
Thanks in advance. --dawn
Leif B. Kristensen
> OK, I'll take a quick stab at a clearer question. If you were writing
> a "data processing 101" type of application, such as a "Pet Store" app
> (if you are familiar with the Java and other Pet Store examples) or
> the Joke Response System described on my web site
> http://www.tincat-group.com/swdev/jokesreq.html and you had complete
> freedom in tool and standards selections, would you be more likely to
> choose a Relational Model to work with your DBMS or an "XML data
> model" or other model that includes attributes with list values?
I'd choose an SQL database anytime. "XML data model" is an oxymoron. XML
may be used to _describe_ your metadata, that's for sure. But to use
XML as a vessel for data storage is like wrapping a floppy disk in a
cubic metre of bubble plastic.
--
Leif Biberg Kristensen
http://solumslekt.org/
dawn
I wouldn't choose an XML database over a SQL database at this point
either. I would choose one with a non-RM data model, however. Cheers!
--dawn
paul c
>...
>
> I am still at a loss to explain the attraction of XML-family standards
> to impressive people such as yourself and Philip Wadler. My only
> working hypothesis is that it's the same reason that Sherlock
> Holmes took cocaine. Even thought it's really unhealthy, there's
> just not enough going on to keep the powerful mind occupied
> otherwise. I note that Wadler has done a lot with XML but
> still says "The problem that it solves isn't very hard, and it
> doesn't solve it very well." This would seem to fit my working
> hypothesis.
Marshall, at the risk of discrediting you by association with somebody
like me who rarely gets the point of any so-called 'technology', I must
say I think you are on to something even if I can't put it as well as
you did. It all reminds me of something Groucho Marx wrote, declining
to give a review for a humour book, something like "from the time i
picked it up until i put it down, i couldn't stop laughing, someday i'm
going to read it".
p
Jan Hidders
>
> I'd like to better understand data independence in terms of
> functionality.
>
> Does it mean that if a new version of a DBMS tool takes the same
> logical specification it can lay the bytes down differently on the disk
> without application code changing?
No.
> Or does the decoupling of physical and logical mean that if I want to
> store attribute data physically "along with" a different entity (table)
> than where it is now (and rework the logical model), no application
> software needs to change?
No.
It means that you can make some changes in the physical model w/o having
to change the logical model. Note that this is different from what you
just said because you were talking about the logical model.
> I'm likely confused on this topic as I have not studied it in depth.
You probably should. It is the singlemost important notion for
understanding what the relational model is about.
-- Jan Hidders
dawn
Jan Hidders wrote:
> dawn wrote:
> >
> > I'd like to better understand data independence in terms of
> > functionality.
> >
> > Does it mean that if a new version of a DBMS tool takes the same
> > logical specification it can lay the bytes down differently on the disk
> > without application code changing?
>
> No.
>
> > Or does the decoupling of physical and logical mean that if I want to
> > store attribute data physically "along with" a different entity (table)
> > than where it is now (and rework the logical model), no application
> > software needs to change?
>
> No.
>
> It means that you can make some changes in the physical model w/o having
> to change the logical model. Note that this is different from what you
> just said because you were talking about the logical model.
I thought that was what I was saying in the first answer. How is this
different?
> > I'm likely confused on this topic as I have not studied it in depth.
>
> You probably should. It is the singlemost important notion for
> understanding what the relational model is about.
It is likely because I have read a bit that I'm confused. Why would
you think that a change in the physical model of a non-relational DBMS
(e.g. PICK) would require reworking the logical model? --dawn
Jan Hidders
> Jan Hidders wrote:
>
>>dawn wrote:
>>
>>>I'd like to better understand data independence in terms of
>>>functionality.
>>>
>>>Does it mean that if a new version of a DBMS tool takes the same
>>>logical specification it can lay the bytes down differently on the disk
>>>without application code changing?
>>
>>No.
>>
>>>Or does the decoupling of physical and logical mean that if I want to
>>>store attribute data physically "along with" a different entity (table)
>>>than where it is now (and rework the logical model), no application
>>>software needs to change?
>>
>>No.
>>
>>It means that you can make some changes in the physical model w/o having
>>to change the logical model. Note that this is different from what you
>>just said because you were talking about the logical model.
>
> I thought that was what I was saying in the first answer. How is this
> different?
The version of the DBMS tool doesn't change. You should be able to
change the physical model w/o changing the tool.
>>>I'm likely confused on this topic as I have not studied it in depth.
>>
>>You probably should. It is the singlemost important notion for
>>understanding what the relational model is about.
>
> It is likely because I have read a bit that I'm confused. Why would
> you think that a change in the physical model of a non-relational DBMS
> (e.g. PICK) would require reworking the logical model?
This is not necessarily true for all such systems but in many of those
the logical and physical model are closely tied together and their
efficiency in fact often depends on this close relationship.
-- Jan Hidders
dawn
> dawn wrote:
> > Jan Hidders wrote:
> >
> >>dawn wrote:
> >>
> >>>I'd like to better understand data independence in terms of
> >>>functionality.
> >>>
> >>>Does it mean that if a new version of a DBMS tool takes the same
> >>>logical specification it can lay the bytes down differently on the disk
> >>>without application code changing?
> >>
> >>No.
> >>
> >>>Or does the decoupling of physical and logical mean that if I want to
> >>>store attribute data physically "along with" a different entity (table)
> >>>than where it is now (and rework the logical model), no application
> >>>software needs to change?
> >>
> >>No.
> >>
> >>It means that you can make some changes in the physical model w/o having
> >>to change the logical model. Note that this is different from what you
> >>just said because you were talking about the logical model.
> >
> > I thought that was what I was saying in the first answer. How is this
> > different?
>
> The version of the DBMS tool doesn't change. You should be able to
> change the physical model w/o changing the tool.
Surely some software somewhere (the OS, the DBMS?) is getting a new
version in order to make for this "change"?
> >>>I'm likely confused on this topic as I have not studied it in depth.
> >>
> >>You probably should. It is the singlemost important notion for
> >>understanding what the relational model is about.
> >
> > It is likely because I have read a bit that I'm confused. Why would
> > you think that a change in the physical model of a non-relational DBMS
> > (e.g. PICK) would require reworking the logical model?
>
> This is not necessarily true for all such systems but in many of those
> the logical and physical model are closely tied together and their
> efficiency in fact often depends on this close relationship.
What is the test for determining whether they are too tightly coupled?
What is it that changes (the "physical model" doesn't resonate with me,
I want to know what software components would change) that should not
require a change in the logical model but does in some non-relational
products? I do not recall ever changing the logical data model in any
software I have written when a new version of anything was released. I
do recall changing COBOL code with a new release of Primos in 1977, but
it was not the logical data model for the indexed sequential files that
had to change.
Still confused. Thanks for your help. --dawn
x
> > This is not necessarily true for all such systems but in many of those
> > the logical and physical model are closely tied together and their
> > efficiency in fact often depends on this close relationship.
> What is the test for determining whether they are too tightly coupled?
> What is it that changes (the "physical model" doesn't resonate with me,
> I want to know what software components would change) that should not
> require a change in the logical model but does in some non-relational
> products? I do not recall ever changing the logical data model in any
> software I have written when a new version of anything was released. I
> do recall changing COBOL code with a new release of Primos in 1977, but
> it was not the logical data model for the indexed sequential files that
> had to change.
Look at Codd 1970 ACM paper.
He describes various data dependencies:
- ordering dependence
- indexing dependence
- access path dependence
then he introduce "a relational view of data".
dawn
I've read it and I'm sure I'm just being dense on this, but I don't
know what it means in practice to a software developer and where I do
understand it, I don't have a full understanding of the risk. I'm
wondering if the cure is worse than the disease.
--dawn
Jan Hidders
> Jan Hidders wrote:
>
>> dawn wrote:
>>
>>> Jan Hidders wrote:
>>>
>>>> dawn wrote:
>>>>
>>>>> I'd like to better understand data independence in terms of
>>>>> functionality.
>>>>>
>>>>
>>>> It means that you can make some changes in the physical model
>>>> w/o having to change the logical model. Note that this is
>>>> different from what you just said because you were talking
>>>> about the logical model.
>>>
>>> I thought that was what I was saying in the first answer. How is
>>> this different?
>>
>> The version of the DBMS tool doesn't change. You should be able to
>> change the physical model w/o changing the tool.
>
> Surely some software somewhere (the OS, the DBMS?) is getting a new
> version in order to make for this "change"?
No. If I decide to restructure the indexes or cluster differently, I'm
still using the same version of the DBMS.
>>> [...] Why would you think that a change in the physical model of
>>> a non-relational DBMS (e.g. PICK) would require reworking the
>>> logical model?
>>
>> This is not necessarily true for all such systems but in many of
>> those the logical and physical model are closely tied together and
>> their efficiency in fact often depends on this close relationship.
>
> What is the test for determining whether they are too tightly
> coupled?
You check if many of the changes in the physical model that might be
needed in the near future will change the logical model.
> What is it that changes (the "physical model" doesn't resonate with
> me, I want to know what software components would change) that should
> not require a change in the logical model but does in some
> non-relational products?
None of the software components change. Are you serious about not
understanding the distinction between the physical model and the logical
model? Try looking in Date's introduction for 'internal level' or
'physical level'.
-- Jan Hidders
dawn
Jan Hidders wrote:
> dawn wrote:
> > Jan Hidders wrote:
> >
> >> dawn wrote:
> >>
> >>> Jan Hidders wrote:
> >>>
> >>>> dawn wrote:
> >>>>
> >>>>> I'd like to better understand data independence in terms of
> >>>>> functionality.
> >>>>>
> >>>>> [...]
> >>>>
> >>>> It means that you can make some changes in the physical model
> >>>> w/o having to change the logical model. Note that this is
> >>>> different from what you just said because you were talking
> >>>> about the logical model.
> >>>
> >>> I thought that was what I was saying in the first answer. How is
> >>> this different?
> >>
> >> The version of the DBMS tool doesn't change. You should be able to
> >> change the physical model w/o changing the tool.
> >
> > Surely some software somewhere (the OS, the DBMS?) is getting a new
> > version in order to make for this "change"?
>
> No. If I decide to restructure the indexes or cluster differently, I'm
> still using the same version of the DBMS.
OK, then I'm pretty sure there are no such administrative features that
can be performed on most commercial databases today that require a
change to the logical data model. I'm sure they don't all have every
feature (clustering, for example).
> >>> [...] Why would you think that a change in the physical model of
> >>> a non-relational DBMS (e.g. PICK) would require reworking the
> >>> logical model?
> >>
> >> This is not necessarily true for all such systems but in many of
> >> those the logical and physical model are closely tied together and
> >> their efficiency in fact often depends on this close relationship.
> >
> > What is the test for determining whether they are too tightly
> > coupled?
>
> You check if many of the changes in the physical model that might be
> needed in the near future will change the logical model.
I haven't seen logical data model changes driven by anything like this
in the MV world but others would know better than I. I suspect that MV
does do things that would be rejected under the heading of data
independence, so I'm curious what, if anything, that might be.
> > What is it that changes (the "physical model" doesn't resonate with
> > me, I want to know what software components would change) that should
> > not require a change in the logical model but does in some
> > non-relational products?
>
> None of the software components change. Are you serious about not
> understanding the distinction between the physical model and the logical
> model?
When I read aobut it, it makes complete sense, but then when I think
about it, I don't recall any time when anything that needed to be done
to the physical database ever caused me to change a logical data model
(although perhaps a data source definition or hardcoded volume in days
gone by).
Is there an example with something primitive like VSAM files (indexed
sequential files) that would illustrate how an application would have
to change the logical data model based on some physical design
decision? I'm clearly missing something (lots). I don't recall ever
having to make such changes.
Thanks --dawn
Jan Hidders
>
> OK, then I'm pretty sure there are no such administrative features that
> can be performed on most commercial databases today that require a
> change to the logical data model.
?? Most of them allow me to add indexes w/o changing the logical model,
or change clustered indexes to non-clustered ones, for example.
-- Jan Hidders
dawn
? Yes, that is what I was saying...? It was perhaps convoluted
wording, so maybe you read it wrong?
Any ideas on a VSAM example of where a physical model change would
prompt a logical data model change? (that was at the end of this
message)
--dawn
x
Have you ever experienced a code strike after a change in the physical model
?
Have you ever changed your code after a change in the physical model ?