Re: General semantics
Date: Fri, 21 May 2010 14:59:40 GMT
Message-ID: <wdxJn.4369$Z6.2264_at_edtnps82>
Erwin wrote:
> On 21 mei, 07:57, Clifford Heath <n..._at_spam.please.net> wrote:
>> paul c wrote: >>> By unary relation I mean a relation with one attribute (which I think is >>> pretty standard lingo, surprised that anybody here wouldn't think that) >> Right, that's what I thought you meant. In which case, it could be a >> representation of either an existential fact type (an object type), >> or a unary predicate over one. The distinction is important. A unary >> predicate creates a subset of the object type it involves. >> >> This distinction was, I believe, the cause of your earlier disagreement. >> >> Further, a unary fact type does not have to be mapped as a unary relation. >> It could be represented as a boolean value in a table of that object type. >> >>> but I have no idea what a 'fact type' is. I know of relation and tuple >>> types but don't know what use terms like 'fact type' or 'unary fact' >>> terms might have. >> Fact oriented modeling has a parallel history with relational modeling. >> It's built on logic rather than sets; those are two sides of one coin. >> Needless to say, it has its own terminology - I tried to introduce some. >> It's a different perspective, equal in power and purity to RM. It has >> some advantages in mapping to natural language somewhat better. Seehttp://ormfoundation.orgfor more details. Ignore it, or look into it, >> but don't scoff at it until you've looked into it.
>
> It seems like the "big brown book" is the bible of the ORM faith.
>
> Looking at the TOC, I see that in the field of constraints, the book
> distinguishes between uniqueness constraints, value constraints,
> subset constraints, equality constraints, exclusion constraints, ring
> constraints, join constraints, ...
>
> That is not an approach that invites to read on.
>
> The RM really has all that is needed to be able to (de facto) do fact-
> oriented modeling : relvars having predicates, plus the CWA.
>
> SIRA_PRISE records the predicate of each relvar in its catalog. The
> predicate of the catalog relvar that does this, is "<relvarname> is a
> relvar whose predicate is <predicate>.". SIRA_PRISE also has a method
> that can generate sentences from this predicate, e.g. the sentence
> "RELVAR is a relvar whose predicate is "<relvarname> is a relvar whose
> predicate is <predicate>.".". Incidentally, and referring to the
> subtitle of that website, the name of the method that does this is
> getTheFacts().
>
> And I never needed any sort of ORM stuff to achieve that.
>
> Nor did I need to make artificial distinctions between the predicates
> of unary catalog relvars (e.g. "<typename> is a DBMS-supported type.")
> and the others.
It is amazing how much has been written about what Codd wrote compared with the few dozen pages he described his approach. Also amazing how he cut through the chaff only to see thousands of people try to re-introduce it. Why are thousands of web pages recommended reading instead of a handful of his short papers? What is it exactly that Codd omitted that needs to be said? Who studies chess without playing it?
It's human nature to take refuge in taxonomies and dogmas of all kinds.
Opportunists see profit by inventing jargon to exploit that weakness and the standard technique of evangelists is to overwhelm their target victims (who are naturally lazy by reason of human nature) by dictating vocabulary and enticing them with intricate thought frameworks that pretend to be self-contained but are really quite insular, eg., in the db field, the various 'modelling' rarely suggest a complete implementation. As in theology, the meaning of belief is then distorted to be the desire to believe, which becomes the product that is actually sold. I'd say the question usually remains: where is the mechanical leverage of any particular 'modelling' religion, eg., what is the point of improved natural language expressiveness without accompanying machine operators, as in 'how does a submarine swim'? Do any of them 'improve' the lack of connection of ER and its ilk with implementation? A model of beliefs is not the same as a model of a useable computer system. Why do people persist in dodging the Information Principle? How can ORM avoid sets without producing equivalents for the set operators? Do the ORM proponents truly believe there is an advantage in postponing implementation or is there just a vested interest in making systems more complicated? The dozens of db's I worked on all had one problem in common, the implementation of unnecessary requirements, nearly always they were introduced by so-called domain experts and their programming flunkies. Once in a while a powerful user would cancel them. Received on Fri May 21 2010 - 16:59:40 CEST