The stupidest design I ever saw

[Mikito Harakiri]

This is a continuation of the old theme, now featuring xml.

<tree>
<node id=0 parent_id=null label='A'>
<node id=1 parent_id=0 label='B'>
<node id=2 parent_id=0 label='C'>
...
</tree>

[Joseph Kesselman]

Mikito Harakiri wrote:

<node id=0 parent_id=null label='A'>

Whatever that is, it isn't XML. XML attribute values must be quoted.

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden

[Marshall Spight]

Joseph Kesselman wrote:

Mikito Harakiri wrote:

<node id=0 parent_id=null label='A'>

Whatever that is, it isn't XML. XML attribute values must be quoted.

Exactly. Once you put quotes around the attribute values, the
design becomes really good, because text based formats are
flexible and nice. You can just put in whatever you want. That's
the right way to manage structured data. "Traditional" databases
are no good, because tables are flat, and the real world is tree
structured. There are lots of structures that you can't express
as a single table, like a linked list.

Another advantage of text formats is that anyone can write a parser
for them. You want as many parsers as possible; that way the
market can decide on what variations of the format are acceptable.
Marshall

[mAsterdam]

Marshall Spight wrote:

Joseph Kesselman wrote:

Mikito Harakiri wrote:

<node id=0 parent_id=null label='A'>

Whatever that is, it isn't XML. XML attribute values must be quoted.

Exactly. Once you put quotes around the attribute values, the
design becomes really good, because text based formats are
flexible and nice. You can just put in whatever you want. That's
the right way to manage structured data. "Traditional" databases
are no good, because tables are flat, and the real world is tree
structured. There are lots of structures that you can't express
as a single table, like a linked list.

Another advantage of text formats is that anyone can write a parser
for them. You want as many parsers as possible; that way the
market can decide on what variations of the format are acceptable.

Your comment is 4 days late.

[Joseph Kesselman]

mAsterdam wrote:

Your comment is 4 days late.

It hit comp.text.xml today. If it's been going on in c.d.t, we don't
know about it. That's the hazard of crossposting.

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden

[Gene Wirchenko]

On Wed, 05 Apr 2006 15:13:51 -0400, Joseph Kesselman
<ke************@comcast.net> wrote:

mAsterdam wrote:

Your comment is 4 days late.

It hit comp.text.xml today. If it's been going on in c.d.t, we don't
know about it. That's the hazard of crossposting.

You missed the joke. It was posted April 5. Four days prior to
that is April Fool's Day.

Sincerely,

Gene Wirchenko

[Marshall Spight]

mAsterdam wrote:

Another advantage of text formats is that anyone can write a parser
for them. You want as many parsers as possible; that way the
market can decide on what variations of the format are acceptable.

Your comment is 4 days late.

Heh. It took me a minute to figure out what you meant; I was
checking the headers for dates when it hit me.
Marshall

[Murdoc]

Marshall Spight wrote:

Joseph Kesselman wrote:

Mikito Harakiri wrote:

<node id=0 parent_id=null label='A'>

Whatever that is, it isn't XML. XML attribute values must be quoted.

Exactly. Once you put quotes around the attribute values, the
design becomes really good, because text based formats are
flexible and nice. You can just put in whatever you want. That's
the right way to manage structured data. "Traditional" databases
are no good, because tables are flat, and the real world is tree
structured. There are lots of structures that you can't express
as a single table, like a linked list.

Actually, that isn't entirely true. Any data structure that has the concept of a 'node' can be
implemented
with a database table, including linked-lists, binary-trees, etc. The only question really is
whether it is
efficient (or necessary) to do so.
--

[Andy Dingley]

On 5 Apr 2006 11:17:49 -0700, "Marshall Spight"
<ma*************@gmail.com> wrote:

the real world is tree structured.

No, the real world is graph structured. Tress are just a limited special
case of graphs.

Another advantage of RDF over XML's data model!

[Bob Badour]

Marshall Spight wrote:

There are lots of structures that you can't express [in traditional dmbses]
as a single table, like a linked list.

You are joking, right?

[JOG]

Andy Dingley wrote:

On 5 Apr 2006 11:17:49 -0700, "Marshall Spight"
<ma*************@gmail.com> wrote:

the real world is tree structured.

No, the real world is graph structured. Tress are just a limited special
case of graphs.

Another advantage of RDF over XML's data model!

you are joking right?

[dawn]

Marshall Spight wrote:

Joseph Kesselman wrote:

Mikito Harakiri wrote:

<node id=0 parent_id=null label='A'>

Whatever that is, it isn't XML. XML attribute values must be quoted.

Exactly. Once you put quotes around the attribute values, the
design becomes really good, because text based formats are
flexible and nice. You can just put in whatever you want. That's
the right way to manage structured data. "Traditional" databases
are no good, because tables are flat, and the real world is tree
structured.

Did you have someone write this post for you, Marshall? Even I
wouldn't make your "the real world is..." statement and some might
expect it from me ;-) Do you want to withdraw it or is that a
statement of faith on your part? --dawn

[Mikito Harakiri]

Andy Dingley wrote:

On 5 Apr 2006 11:17:49 -0700, "Marshall Spight"
<ma*************@gmail.com> wrote:

the real world is tree structured.

No, the real world is graph structured. Tress are just a limited special
case of graphs.

Another advantage of RDF over XML's data model!

"We learn from history that we learn nothing from history."

This becomes a repetitive theme nowadays.

[Mikito Harakiri]

JOG wrote:

Andy Dingley wrote:

On 5 Apr 2006 11:17:49 -0700, "Marshall Spight"
<ma*************@gmail.com> wrote:

the real world is tree structured.

No, the real world is graph structured. Tress are just a limited special
case of graphs.

Another advantage of RDF over XML's data model!

you are joking right?

Andy's posting history doesn't leave any doubt that he is serious.
Anyway, the link to RDF turned out to be informative. Here is what I
found:

<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xml:base="http://example.org/schemas/vehicles">

<rdf:Description rdf:ID="MotorVehicle">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
</rdf:Description>

<rdf:Description rdf:ID="PassengerVehicle">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="Truck">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="Van">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="MiniVan">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#Van"/>
<rdfs:subClassOf rdf:resource="#PassengerVehicle"/>
</rdf:Description>

</rdf:RDF>

The folks who wrote this apparently have no idea that graph is defined
by the set of nodes and edges between them. They wrap their naive
understanding what the graph is into XML cludgy syntax and claim it to
be a superior solution. To what problem may I ask?

[Neo]

> The folks who wrote this apparently have no idea that graph is defined by the set of nodes and edges between them. They wrap their naive understanding what the graph is into XML cludgy syntax and claim it to be a superior solution.
..
What is the better solution? Could you show it (possibly using the
vehicle classes above)?

[JOG]

Mikito Harakiri wrote:

JOG wrote:

Andy Dingley wrote:

On 5 Apr 2006 11:17:49 -0700, "Marshall Spight"
<ma*************@gmail.com> wrote:

>the real world is tree structured.

No, the real world is graph structured. Tress are just a limited special
case of graphs.

Another advantage of RDF over XML's data model!
you are joking right?

Andy's posting history doesn't leave any doubt that he is serious.
Anyway, the link to RDF turned out to be informative. Here is what I
found:

<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xml:base="http://example.org/schemas/vehicles">

<rdf:Description rdf:ID="MotorVehicle">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
</rdf:Description>

<rdf:Description rdf:ID="PassengerVehicle">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="Truck">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="Van">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="MiniVan">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#Van"/>
<rdfs:subClassOf rdf:resource="#PassengerVehicle"/>
</rdf:Description>

</rdf:RDF>

Don't you just love the way that xml is human readable and
self-describing.

The folks who wrote this apparently have no idea that graph is defined
by the set of nodes and edges between them. They wrap their naive
understanding what the graph is into XML cludgy syntax and claim it to
be a superior solution. To what problem may I ask?

I believe the problem was that semantic network research had finally
come to a sticky end in the AI field, so its proponents had to find a
new home for their nonsense. It seems that with RDF they have indeed
solved this...

[Vadim Tropashko]

Neo wrote:

The folks who wrote this apparently have no idea that graph is defined by the set of nodes and edges between them. They wrap their naive understanding what the graph is into XML cludgy syntax and claim it to be a superior solution.

.
What is the better solution? Could you show it (possibly using the
vehicle classes above)?

To what kind of problem? Do you really insist on vehicle classification
in the first place? You may want spend some time on Bruce Jacobs site
where he advocates that classification system for data management
problems is a poor solution in general.

Note, that I'm not saying that graph related problems don't exist. I
merely challenge their applicability in this case.

Now, storing a graph in the database is no brainer.

table Nodes (
id number,
... -- content
)

table Edges (
tail number,
head number,
... -- more content, if edges are labeled
)

I have two chapters about trees and graphs in my book.
http://www.rampant-books.com/book_20...ing_styles.htm

[Marshall Spight]

Marshall Spight wrote:

Once you put quotes around the attribute values, the
design becomes really good,

To everyone who asked: yes, I was joking.
Marshall

[Neo]

> table Nodes (id number, ... -- content)

table Edges (tail number, head number, ... -- more content, if edges are labeled)

How do I use the above schema to model the vehicle classes shown in the
RDF example given earlier? I still don't see it.

[Vadim Tropashko]

Neo wrote:

table Nodes (id number, ... -- content)
table Edges (tail number, head number, ... -- more content, if edges are labeled)

How do I use the above schema to model the vehicle classes shown in the
RDF example given earlier? I still don't see it.

No, you first please demonstrate that the above classification serves
some useful purpose.

I prefer to write a database schema for cities and travel links
instead. Here we go:

table Cities (
name string
)
table Connections (
tail string,
head string,
distance integer
)

Example query: find the shortest path between two cities.
Surprisingly, it's not easy to express this or parts explosion kind of
query in XQuery (which is allegedly a superior tool for graph/tree
related problems). You can compare XQuery solution

define function total (element PART $part)
returns element PART {
let $subparts := $part/PART/total(.)
return
<PART NAME="$part/@NAME"
COST="$part/@COST + sum($subparts/@COST)">{
$subparts
}</PART>
}

from
http://homepages.inf.ed.ac.uk/wadler...afp-slides.pdf
with SQL (which I just mindlessly copying and pasting from my book
without really making sure they accomplish the same thing):

select leaf, sum(factoredQuantity) from (
select product(Quantity) factoredQuantity,
first(Part) root, last(SubPart) leaf
from AssemblyEdges
connect by prior Part = later SubPart
) where root = 'Bicycle'
group by leaf

[dawn]

Vadim Tropashko wrote:

Neo wrote:

The folks who wrote this apparently have no idea that graph is defined by the set of nodes and edges between them. They wrap their naive understanding what the graph is into XML cludgy syntax and claim it to be a superior solution.

.
What is the better solution? Could you show it (possibly using the
vehicle classes above)?

To what kind of problem? Do you really insist on vehicle classification
in the first place? You may want spend some time on Bruce Jacobs site
where he advocates that classification system for data management
problems is a poor solution in general.

Could you provide a URL for his site? Thanks. --dawn

[Vadim Tropashko]

dawn wrote:

Vadim Tropashko wrote:

Neo wrote:

> The folks who wrote this apparently have no idea that graph is defined by the set of nodes and edges between them. They wrap their naive understanding what the graph is into XML cludgy syntax and claim it to be a superior solution.
.
What is the better solution? Could you show it (possibly using the
vehicle classes above)?

To what kind of problem? Do you really insist on vehicle classification
in the first place? You may want spend some time on Bruce Jacobs site
where he advocates that classification system for data management
problems is a poor solution in general.

Could you provide a URL for his site? Thanks. --dawn

http://www.geocities.com/tablizer/oopbad.htm#overeng

Keep in mind that his site is more obnoxious than dbdebunk, and he
certainly fails short of being able to actually deliver a promised
table-oriented language, but some parts are worth reading.

[Volker Hetzer]

Marshall Spight wrote:

Joseph Kesselman wrote:

Mikito Harakiri wrote:

<node id=0 parent_id=null label='A'> Whatever that is, it isn't XML. XML attribute values must be quoted.

Exactly. Once you put quotes around the attribute values, the
design becomes really good, because text based formats are
flexible and nice. You can just put in whatever you want. That's
the right way to manage structured data. "Traditional" databases
are no good, because tables are flat, and the real world is tree
structured. There are lots of structures that you can't express
as a single table, like a linked list.

Another advantage of text formats is that anyone can write a parser
for them.

Up to here I actually took this seriusly.
You want as many parsers as possible; that way the
market can decide on what variations of the format are acceptable.

Troll! You almost got me! :-)

Volker

[Andy Dingley]

Mikito Harakiri wrote:

Andy's posting history doesn't leave any doubt that he is serious.
8-) I hear the Pope has a bit of thing about heresy too.

Anyway, the link to RDF turned out to be informative.

Can I please ask a couple of things of people posting to this thread

If you're a c.d.t regular and you x-post into c.t.x, then please post
some links back to context. I get the feeling I've fallen into an old
argument here and I don't know what the background is.

Secondly, if you look at RDF stuff, then look at the W3C documentation
pack from early 2004.
http://www.w3.org/RDF/
The docs before this date were unfriendly and unclear (to say the
least) and the Feb2004 rewrite was a damn good bit of work - it's worth
reading the right version. Anything older than this (particularly last
century) is quite probably very misleading.
Now, let battle commence!

[-CELKO-]

Congrats on the book!!

[dawn]

Marshall Spight wrote:

Marshall Spight wrote:

Once you put quotes around the attribute values, the
design becomes really good,

To everyone who asked: yes, I was joking.

Wheeew! It's not that I don't enjoy discussions about "the real world"
but I like to keep the math folks and those living in the real world
apart. smiles --dawn

[Neo]

> > > table Nodes (id number, ... -- content)

table Edges (tail number, head number, ...)
How do I use the above schema to model the vehicle classes shown in the
RDF example given earlier? I still don't see it.

No, you first please demonstrate that the above classification serves
some useful purpose.

It may serve the purpose of allowing a large car dealership to narrow
down the list of vehicles to offer based on a general category
specified by a customer (ie mini-van, economy, economy/luxury,
utility/hybrid, etc).
Bruce Jacobs advocates that classification system for data management
problems is a poor solution in general.
While I accept that implementation by a particular methodology may have
limitations or problems (ie as in multiple inheritance in OOP), are you
saying that classification, by itself, is a poor solution to data
management? If so, why would human being rely on it so much? For
example, if someone tells me thing X is a helicopter, it allows me to
infer many characteristics. Next, if they tell me it is also a jet, it
allow me to infer additional prominent characteristics and doubts some
of the minor ones. For instance, I can now assume that it not only
hovers but flies very fast, but less certain about it's cockpit/cabin
environment. After learning more details, I might classify thing X
predominantly in a new class (ie UFO?) but still keep it as a minor one
in the old ones. I agree that various classes should not be arranged in
a hierarchy (as in the earlier XML/RDF example) and that each thing
simply belongs to 0 to many classes. In addition, human's data
management system probably include weighting factors as to how strongly
a thing belongs in a particular class and also for properties and
methods associated with a class.
Surprisingly, it's not easy to express this or parts explosion kind of
query in XQuery (which is allegedly a superior tool for graph/tree
related problems). You can compare XQuery solution ... with SQL ...

Thanks for presenting the two solutions.

[Vadim Tropashko]

Neo wrote:

No, you first please demonstrate that the above classification serves
some useful purpose.

It may serve the purpose of allowing a large car dealership to narrow
down the list of vehicles to offer based on a general category
specified by a customer (ie mini-van, economy, economy/luxury,
utility/hybrid, etc).

Just an attribute/column would suffice.

Bruce Jacobs advocates that classification system for data management
problems is a poor solution in general.

While I accept that implementation by a particular methodology may have
limitations or problems (ie as in multiple inheritance in OOP), are you
saying that classification, by itself, is a poor solution to data
management? If so, why would human being rely on it so much? For
example, if someone tells me thing X is a helicopter, it allows me to
infer many characteristics. Next, if they tell me it is also a jet, it
allow me to infer additional prominent characteristics and doubts some
of the minor ones. For instance, I can now assume that it not only
hovers but flies very fast, but less certain about it's cockpit/cabin
environment. After learning more details, I might classify thing X
predominantly in a new class (ie UFO?) but still keep it as a minor one
in the old ones. I agree that various classes should not be arranged in
a hierarchy (as in the earlier XML/RDF example) and that each thing
simply belongs to 0 to many classes. In addition, human's data
management system probably include weighting factors as to how strongly
a thing belongs in a particular class and also for properties and
methods associated with a class.

IMO the formal concept analysis folks nailed the right approach to
categorization theory. There are two sets: formal objects and formal
attributes. Check up the "Formal Concept Analysis in Information
Science" article by Uta Priss -- it is written for general audience.

[Neo]

> > > please demonstrate that the above classification

serves some useful purpose.
It may serve the purpose of allowing a large car dealership to narrow
down the list of vehicles to offer based on a general category
specified by a customer (ie mini-van, economy, economy/luxury,
utility/hybrid, etc).

Just an attribute/column would suffice.

Would you consider such a solution to be normalized/flexible?
Check up the "Formal Concept Analysis in Information Science"
article by Uta Priss

Thanks.

[Troels Arvin]

On Wed, 05 Apr 2006 19:06:00 -0700, Vadim Tropashko wrote:

I have two chapters about trees and graphs in my book.
http://www.rampant-books.com/book_20...ing_styles.htm

Interesting. Please post a message in this group when the book has been
published.

--
Greetings from Troels Arvin

[mAsterdam]

-CELKO- wrote:

Congrats on the book!!

Seconded.
Please don't forget to drop us a note when it is available :-)

[JOG]

mAsterdam wrote:

-CELKO- wrote:

Congrats on the book!!

Seconded.
Please don't forget to drop us a note when it is available :-)

I gotta say, I like the cover too....

[Marshall Spight]

Vadim Tropashko wrote:

There are two sets: formal objects and formal
attributes. Check up the "Formal Concept Analysis in Information
Science" article by Uta Priss -- it is written for general audience.

Here is a link:

http://upriss.org.uk/papers/arist.pdf
Marshall

[topmind]

Marshall Spight wrote:

Joseph Kesselman wrote:

Mikito Harakiri wrote:

<node id=0 parent_id=null label='A'>
Whatever that is, it isn't XML. XML attribute values must be quoted.

Exactly. Once you put quotes around the attribute values, the
design becomes really good, because text based formats are
flexible and nice. You can just put in whatever you want. That's
the right way to manage structured data. "Traditional" databases
are no good, because tables are flat, and the real world is tree
structured.

Really? Where is the proof that that? I find hierarchies artificial and
limiting when trying to model stuff. They are very poor at handling
more than about 3 orthogonal categories.

There are lots of structures that you can't express
as a single table, like a linked list.
This is wrong, but somebody already pointed that out.

Another advantage of text formats is that anyone can write a parser
for them. You want as many parsers as possible; that way the
market can decide on what variations of the format are acceptable.
Comma-seperated value format is far easier to build a parser for than
XML.

XML is for people who don't "get" relational IMO. XML is neither good
for (most) human eyes nor computerization of info because it encourages
poor normalization and over-use of hierarchies. If you go down the
nested text route, then LISP ess-expressions would be better anyhow. It
is usually better repetition factoring, for one.


Marshall

-T-

[Marshall Spight]

topmind wrote:

Marshall Spight wrote:

Exactly. Once you put quotes around the attribute values, the
design becomes really good, because text based formats are
flexible and nice. You can just put in whatever you want. That's
the right way to manage structured data. "Traditional" databases
are no good, because tables are flat, and the real world is tree
structured.

Really? Where is the proof that that?

It was a joke. Read it again in ironic mode.

Comma-seperated value format is far easier to build a parser for than
XML.

XML is for people who don't "get" relational IMO.

My take is that the Children of SGML have had such great success
with document processing and especially with the web, that it's
gone to their head. They have overgeneralized their techniques
until they feel they have the right answer for structured data
management. In fact, using XML to manage structured data
makes about as much sense as doing document management
in SQL.
Marshall

[Peter Flynn]

Marshall Spight wrote:

Joseph Kesselman wrote:

Mikito Harakiri wrote:

<node id=0 parent_id=null label='A'> Whatever that is, it isn't XML. XML attribute values must be quoted.

Exactly. Once you put quotes around the attribute values, the
design becomes really good,

Well, tolerably good. It's poor design to use the attribute name
"id" for a value which may not be an XML ID, even though this may
not be necessary to the design, simply because it's ambiguous and
misleading. The ID data type is there for a purpose, and if it is
not being used, then it is not a good idea to use a name which
implies that it is.

Oh, and the node element tag should be an empty element.
because text based formats are
flexible and nice. You can just put in whatever you want.
Sadly, people do do just that :-)
That's
the right way to manage structured data. "Traditional" databases
are no good, because tables are flat, and the real world is tree
structured.
Some of it. A lot of my work consists in unwedging users from
unpleasant places they have gotten themselves jammed into because
someone told them the world was a tree, and they tried to apply
this to a linear structure which was not tree-shaped.
There are lots of structures that you can't express
as a single table, like a linked list.

Another advantage of text formats is that anyone can write a parser
for them. You want as many parsers as possible; that way the
market can decide on what variations of the format are acceptable.

Only if the market is well-informed. A deliberately mis-informed
market makes a wonderfully blunt instrument for making your chosen
format acceptable regardless of its usefulness.

///Peter
--
XML FAQ: http://xml.silmaril.ie/
"When all you have is a chainsaw, everything looks like a tree"

[Neo]

> "Formal Concept Analysis in Information Science" article by Uta Priss

http://upriss.org.uk/papers/arist.pdf

Both the XML example given earlier which modelled vehicle
classification as a hierarchy and Formal Concept Analysis which also
employs a classification hierarchy (see example in Fig 2) are flawed in
that it can lead to situations where a thing classified by it immediate
parent, isn't classified by the parent of the parent.

Take a look at all the links between various nodes in Fig 2 and
determine if there is a consistent relationship between nodes taking
into account direction of the link. Basically the most consistent
relationship seems to be that a lower node is an instance/example of
the upper node. You can ignore top and bottom nodes which represent
Universal Concept and NULL respectively. So what is the relationship
between mammal and cartoon? Is cartoon a mammal?

[Mikito Harakiri]

Neo wrote:

"Formal Concept Analysis in Information Science" article by Uta Priss
http://upriss.org.uk/papers/arist.pdf
Both the XML example given earlier which modelled vehicle
classification as a hierarchy

I don't care about anything related to XML, unless my job requires it.
and Formal Concept Analysis which also
employs a classification hierarchy (see example in Fig 2) are flawed in
that it can lead to situations where a thing classified by it immediate
parent, isn't classified by the parent of the parent.
Wrong. The formal concepts lattice defines a partial order relation. If
an object and a formal attribute are ordered by the lattice order
relation then the object is in the "is a" relation to the concept
defined by the attribute. There is no requrement for the attribute to
be the immediate node on the leattice. Example: Garfield "is a" mammal.
Take a look at all the links between various nodes in Fig 2 and
determine if there is a consistent relationship between nodes taking
into account direction of the link. Basically the most consistent
relationship seems to be that a lower node is an instance/example of
the upper node. You can ignore top and bottom nodes which represent
Universal Concept and NULL respectively. So what is the relationship
between mammal and cartoon? Is cartoon a mammal?

Both cartoon and mammal are formal attributes. If two attribute are in
the lattice partial order relation, then one concept is a subclas of
the other. Cartoon is a mammal in this example..

[Neo]

> Cartoon is a mammal ...

Your joking, right? Cartoon is not a mammal. It is a classification
that has no direct relationship to mammal.

... then one concept is a subclas of the other

And that is the crux of the problem; in that it can lead to situations
where a thing classified by the subclass, isn't necessarily classified
by the respective class. For example, a robotic dog manufactured by
Sony, is a dog, is a toy and is a machine, but it isn't necessarily a
mammal (unless it actually has mammary glands which produce milk for
its young, etc).

[JOG]

RE: Marshall's original post - I can't be the only one who saw the
irony in that right? Or are all those replies being post-ironic?

Either way great post Mr Spight. Its rare on cdt that I read a post and
actually laugh outloud. (although that has happened more and more
recently...)

[Mikito Harakiri]

Neo wrote:

Cartoon is a mammal ...
Your joking, right? Cartoon is not a mammal.

I'm serious. It's just an example. Look into the table on figure 1
which is the basis for the lattice on figure 2. If you don't want
cartoon to be classified as mammal, which squares should be unchecked?
And that is the crux of the problem; in that it can lead to situations
where a thing classified by the subclass, isn't necessarily classified
by the respective class. For example, a robotic dog manufactured by
Sony, is a dog, is a toy and is a machine, but it isn't necessarily a
mammal (unless it actually has mammary glands which produce milk for
its young, etc).

Just make the incidence table of objects and their attributes as the
article did and derive lattice from it. If you are unhappy with the
resulting classification, this means you have to redo the incidence
table all over again. In your example, you don't want robotic dog to be
considered as a mammal? Just uncheck the box.

[Marshall Spight]

JOG wrote:

Either way great post Mr Spight. Its rare on cdt that I read a post and
actually laugh outloud. (although that has happened more and more
recently...)

I thank you, sir! I always say, if there is a cheap laugh
to be had, you'll know where to find me.
Marshall

[Richard Smol]

Mikito Harakiri wrote:

This is a continuation of the old theme, now featuring xml.

<tree>
<node id=0 parent_id=null label='A'>
<node id=1 parent_id=0 label='B'>
<node id=2 parent_id=0 label='C'>
...
</tree>

You forgot to put quotes around the arguments. And for the rest the
only proper comment is: it depends.

RS

[Neo]

> > > Mikito: Cartoon is a mammal ...

Neo: Cartoon is not a mammal.

Mikito: Look into the table on figure 1
which is the basis for the lattice on figure 2.
If you don't want cartoon to be classified as mammal,
which squares should be unchecked?

First there is no systematic method that allows one to create the
hierarchy (fig 2) on the basis of the table (fig1) (even after ignoring
the top most and bottom most nodes which represent Universal and NULL
respectively). If you know what that method is, please state it so that
anyone can verify it. Try this, rename all objects and classes as
consecutive letters. Then try to create the hierarchy. In particular,
the links to mammal.

Second, you can't unclassify cartoon as a mammal in the table because
it isn't being classified as an mammal. Both cartoon and mammal are
classifications listed across the top. And as the author states "The
elements on the left side are formal objects; the elements at the top
are formal attributes [aka classes]; and the relation between them
[objects and classes] is represented by the crosses." Please state THE
square/cell (and there should be only one, if any at all, otherwise why
the redundancy) to uncheck which unclassifies cartoon as a mammal
without also unclassifying Garfield and Snoopy as cartoons? A portion
of the table shown below:

______ cartoon real dog cat mammal
Garfield __X___ ___ ___ _X_ __X____
Snoopy __X___ ___ _X__ ___ __X____

[B Faux]

"Marshall Spight" <ma*************@gmail.com> wrote in message
news:11*********************@i40g2000cwc.googlegro ups.com...

JOG wrote:

Either way great post Mr Spight. Its rare on cdt that I read a post and
actually laugh outloud. (although that has happened more and more
recently...)

I thank you, sir! I always say, if there is a cheap laugh
to be had, you'll know where to find me.
Marshall

ROFLMAO!!

I wasn't sure until I got to...

"Another advantage of text formats is that anyone can write a parser
for them. You want as many parsers as possible; that way the
market can decide on what variations of the format are acceptable."

That just confirmed it for me.

BFaux ;-)