Thanks so much, Doug, for taking the trouble to look at my ramble.
You clarify everything I said, and I agree with all your clarifications. I have been trying to discuss what we find in a domain we want to analyze and we ***choose to model** as things, individuals, (values of variables) etc. ...., and for what reasons we make that choice, vs. what we choose to represent as a class, relation, predicate, etc .... and *why*. I neglected to explain this, so am very glad that somebody saw this context for my suggestions.
With respect to models of cars, I think the choice depends again on the context. From the car seller and consumer viewpoints, I see how treating product models as #$ProductTypeByBrandVersion classes would be most appropriate, with the cars as instances. On the other hand, from the auto manufacturer's viewpoint, the product model perhaps fits the more complex #$ConceptualWork pattern better.
On Tue, Dec 18, 2012 at 3:50 PM, doug foxvog <doug@xxxxxxxxxx> wrote:
On Sun, December 16, 2012 10:31, William Frank wrote:
> Flights are a great example, but a rather complex one. I believe that
> ***many** human artifacts are of this same nature as flights. We define a
> pattern, and subpatterns, and individual instances of the pattern,
> Sometimes with intermediaries, but use them all like individuals of some
> sort.
So long as the relationship between a pattern and a thing which falls into
that pattern is not one of a class/type and instance of the class/type,
both are individuals.
> People have two separate concepts: individual (a characterization)
> and instance (a relationship).
I agree that "instance" represents a relationship between two things: a
type and something that is of that type. I'm not sure of what is meant by
an individual being a characterization, however. I would think that
types, relationships, statements, and physical objects can all be
characterized. I'm not sure what couldn't be characterized.
> Take *a* book, like "Moby Dick". There are many different editions of
> Moby Dick, each edition has a number of printings, and each printing has a
> number of copies. Moby Dick itself has a life cycle, it was conceived,
> in writing, written, all knowledge of it lost, perhaps.
Look at what Cyc has done with #$ConceptualWork to distinguish these
things. The above paragraph starts with the intangible individual conceptual
work (specifically an instance of #$Book-CW), "Moby Dick" (which happens
to be the prototype that Cyc uses). The editions are instances of
#$TextuallySpecificWork, which relate to the original work via
#$editionOfBook. There are printing events, instances of
#$PublishingWrittenMaterial, but this doesn't seem to be what you mean by
"printings". The individual #$BookCopy s next referred to are related to
the original #$Book-CW via #$instantiationOfWork.
> Each edition has a life cycle, each printing also,
> down to each copy having a life cycle of its own.
Sure. None of these things are treated as classes by Cyc.
> The same would be true of the 1973 Ford F-150.
I certainly see similarities between product models and conceptual works.
However, Cyc has been able to represent product models as classes, with
the individual products being instances of those classes. Since the
classes are instances of metaclasses (such as #$ProductTypeByBrand and
#$ProductTypeByBrandVersion) and are inter-related by predicates (such as
#$versionOfProductBrand) appropriate statements about the product life
cycles can be made even though the product models/versions/types are
classes.
> Also of a form like a credit application form.
A form would be a conceptual work. Variations on the form would be
treated as variations on any other conceptual work.
> We define the template,
> then we fill it out and get something else, based on the template,
What is filled out is a copy of the form. The copy may be physical or
electronic. An unlimited number of them may be generated from the
(conceptual) form.
> so too for a class in a
> class-object-oriented programming language.
Such a "class" is an individual conceptual work -- as are the class
instances in the programming language.
> As Hans and Mathew emphasize, the sine-qua-non of an **individual** is
> that it has a life cycle.
This definition excludes atemporal individuals and includes types that
have life cycles.
Classes (or types of things) sometimes have life cycles, too. Consider a
species. It has a starting time (and location); it geographically
spreads over time; it has temporal stages through which it progresses
including the IUCN's set of "conservation status" states: (the
anthropomorphically named) "least concern", "near threatened",
"vulnerable", "endangered", "critically endangered", "extinct in the
wild", and "extinct".
I prefer to use the term "individual" to mean everything that is not a
"class", partitioning the universe of discourse into Class and Individual.
This meaning of "individual" would have "physical thing", "time period",
"data type", "conceptual work", "predicate", and "statement" as
subclasses. An important subclass of "class" would be "class of
individuals" (the class of all individuals); but metaclasses are important
for many purposes.
The concept of a "thing with a life cycle" could be useful. This would be a
class that has both classes and non-classes (which i'd prefer to call
"individuals") as instances.
Having a debate over what a word or term "really means" is common, and not
very useful (imho) since most words have multiple (often many) meanings.
However, in a given field, agreement on the meaning of a term (within that
field) can be very useful.
> Human artifacts are in this way unlike things in nature, like frogs, where
> we don't define the pattern, but FIND it.
We find temporal patterns of *types* of things in nature (see above).
> So, whether one wants, for some philosophical reason,
> to deny individuality to anything but physical things,
I'm not sure if any of us wish to do this. i certainly don't.
> or to anything that can be used as a pattern for another thing,
Ditto.
> individual 'books' are very different from species of frogs,
> and one way or another,
> an effective model of the the way the two operate needs to take
> that into account. I am not looking for what seem to me like glib
> explanations of how these things are the same, justifying the status quo
> of almost all computer science ontology work
> (the unchallenged ontology of these ontologies) .
> I think it would be more effective to spend more time considering how,
> in practice, we treat human artifacts based on patterns in
> a special way, before applying this Procrustean bed.
I think that Cyc's #$ConceptualWork is a good starter. #$Specification is
a subtype of #$ConceptualWork and applies to human designed patterns.
I would encourage a discussion on whether product types should be kept
as classes with individual products which are bought or rented being their
instances, or whether they should be modeled as individuals, with different
relationships holding between them and their product types. Of course,
in a DL logic, the product types are instances of the meta-types (which are
encoded as classes). The DL systems would normally not also refer to the
instances of the product types, so this should not be a factor.
-- doug foxvog
> ...
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
--
William Frank
413/376-8167
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (01)
|