Pat, (01)
Many thanks for your detailed response, nicely brief and to the
point, so thank you for the example you set me too! (02)
My detailed answers are embedded below. (03)
> At 9:03 AM +0200 2/21/08, Christopher Spottiswoode wrote:
>
>>
>>All formal MACK statements are triple-entity binary
>>entity-relationship facts. So, glossing over a few less
>>important details, here is a depiction of a well-formed though
>>minimalist ("elementary" or "atomic"?) Form:
>>
>>User GetsFrom Supplier.
>>
>>In its terms you Form (or "inForm"?) relevant situations into
>>facts like:
>>
>>John GetsFrom George.
>>and its inverse fact in terms of the inverse relationship:
>>George Supplies John.
>
> What specifies that GetsFrom is the inverse of Supplies? Is this fact
> also a Form? In OWL/RDF for example one could write (in N3 notation,
> using URI syntax to be legal) (04)
As you have now seen in my later post clarifying and amplifying this 2nd
instalment, the inverse definition is part of the metadata of the
relationship, very much as in this example of yours: (05)
>
> ex:GetsFrom owl:inverseOf ex:Supplies .
>
>
>>Is it too early, Pat, to say if that Form meets - or may seem to
>>meet - your ideal (ignoring all other apparent aspects of the
>>Form)?
>
> So far it seems rather similar to RDF, which isn't a bad start, but
> needs supplementation with more expressive notations. IN particular,
> one will need something like a universal quantifier and something
> like negation and implication. (06)
Please remind me to return to this question after another instalment or
two or three? I think you might see the equivalent functionality is there
already, mostly implicit or by other means. (07)
But can I repeat my question as to whether you were happy that the
"purity" (my term) of the sample atomic Form in its (your phrase:) degree
of elimination of contextual sensistivity as far as possible? (08)
>
>>The main facts implicit in that definition are: User IsA Type;
>>Supplier IsA Type; and GetsFrom IsA Relationship.
>
> To translate to RDF use this table:
>
> IsA rdf:type
> Type rdfs:Class (or possibly owl:Class)
> Relationship rdf:Property (09)
Ok, that's fine, more or less, at this stage. (010)
>
>> Already
>>assumed are facts like these: IsA IsA Relationship;
>>Relationship IsA Type; even Type IsA Type; and all their
>>inverse facts. (Let's not discuss names such as "Type" and
>>"Entity" just yet! Nor how this linear exposition obscures how
>>much easier and more natural Form definion and fact declaration
>>will be in the online environment the second pillar will grow
>>into.)
>>
>>But we have the beginnings of some important MACK-unique
>>features here already! Please bear with me:
>>
>>User and Supplier have no properties other than the usually
>>implicit ones indicated and the fact that they bear the
>>thereby-defined Relationship with each other.
>
> Have no other, or are not asserted to have any other? That is, is it
> *prohibited* for these to have any other properties? (OWL-DL would
> say yes to this question, RDF would say no. A basic difference in
> knowledge-architectural style.) (011)
Have no other because no other specified yet. An entity is an instance of
a type if it has the specified "ReqRels" or RequiredRelationships,
inherited or own, explicit or inferable. Other properties can optionally
be added by a suitably authorized user, or in an appropriate context.
Prohibiting further properties? There is at present no such metadata
defined, but that kind of facility is developer-extensible. We'll see a
lot more of that. Also, the UI has many features you haven't imagined
yet, and the way the AOS can and does reflectively know and manage itself
makes everything very controllable. So, for example, other attendant
facts such as ownership of Forms and freezing of specs are normal aspects
of application lifecycle and management. And remember also from the
supplement to this 2nd instalment that all such operations take place on
the "living organism", for all the understandable ho-hum at such
apparently fanciful notions! (012)
>
>> They are at the
>>highest or most abstract level at which they make sense. A User
>>is nothing except that one of them may get from a Supplier (and
>>usually implicitly also be in the InverseRelationship with a
>>Supplier). It doesn't even have to have a name or tag.
>
> Like a blank node in RDF. (013)
Somewhat more, I think, as I shall try to show before long. (014)
>
>>
>>So in a sense the relationship is the primary idea.
>>Non-Relationship Entities exist solely by virtue of their
>>Relationships with other Entities.
>
> Quite. A basic insight of relational logic since Tarski. (015)
Yes, quite. (016)
And every time I agree in such a way I find it difficult not to point out
that The Mainstream can be very mainstream too. (017)
But I hope you noticed later that with that observation about the
relationship I was building up to the Generalized Object Model point?
That will become relevant when we review the OO aspects of MACK and see
how MACK gives all the benefits sought by OO, only better. There is a
surprising nexus of features here, for example nicely solving the classic
OO problem of asynchronous or deferred method invocation, or rather the
lack thereof. (018)
>
>> (I can't resist noting that
>>a refinement is our South African notion of "Ubuntu": "We are
>>who we are through other people.") There is no such thing in
>>MACK as a standalone Entity, though it may be known with nothing
>>more than an IsA fact, even as in X IsA Entity. But none of all
>>that is new, of course. The unique bit starts now:
>>
>>More than somewhat analogous to introducing RDF's subproperty,
>>we now start building up to the "filthy-lucre" or commercial
>>market by defining a Subform of our first one:
>>
>>Customer BuysFrom Vendor.
>>
>>So, clearly, Customer IsSubtypeOf User and Vendor IsSubtypeOf
>>Supplier, but more noteworthy is that BuysFrom Implies GetsFrom
>
> Is that stated somehow (how?) or is it implicit? On what basis? If I
> write any triple
>
> Customer Foodle Vendor
>
> does it follow that Foodle implies GetsFrom? (019)
No, not at all. A type pair often has multiple relationships between
them, e.g Customer HasInvestigated Product and, independently (i.e. not as
a subproperty), Customer HasBought Product. So, yes, the Implies fact
here is explicit metadata on the relationship. (020)
>
>>(in which you may also note why I suggest capitalizing
>>Relationship names/tags)
>>
>>But does that mean that (in a manner of speaking)
>>{Anne-as-Customer BuysFrom Lynne-as-Vendor} Implies
>>{Anne-as-Customer GetsFrom Lynne-as-Vendor}?
>
> What does the -as- connective mean? Is Anne the same entity as
> Anne-as-Customer? If so, what is the meaning attached to the longer
> form? If not, what is the difference between them? (021)
That "in a manner of speaking" rather elliptically meant that the
constructions were not regular or even meaningful as syntactic elements.
Thus, as in the example below, "Anne-as-Customer" or, perhaps better,
"Anne the Customer", in her 'less abstracted' state, is now known to have
filthy-lucre-related activities which she may want to hide from people
whom she wants to think of her as a pure and innocent merely-sharing User.
I now recall having seen this kind of phenomenon referred to as
information leakage via metadata. And as I had noted, Relational Views
can also hide such apparently embarrassing metadata-existence indications.
I did not note, however, that I had read somewhere that such views are in
practice seldom used for access control. Certainly, that is consistent
with my own experience in the field, and incoherence of architecture and
design is what I'd blame for such neglect. (022)
The purpose of my original example and reflections on it was to draw
attention to the importance of fine differences between levels of
abstraction, as you can see from the later buildup to the MRCL notion.
But thank you for pushing me into trying to clarify my point. You will
see how this scene leads on to fine control over processing, with often
spontaneous, surprising and useful switches of perspective. (023)
>> Yes and no. There
>>is only one Anne and only one Lynne, so yes, of course Anne
>>GetsFrom Lynne, so OO-inheritance's substitutability has its
>>parallel here (as in the Liskov Substitution Principle). But
>>no, the GetsFrom fact is an abstracted fact, about the more
>>abstracted subjects and objects.
>
> Tell us what you mean by 'abstracted subjects'.
>
> You seem here to have contradicted yourself. If there is only one Anne
> then
> Anne = Anne-as-Customer
> so the 'more abstracted' Anne is the same as the plain Anne. You need
> to state what you mean more clearly. (024)
Yes, you are right, as in my explanation above. (025)
>
>> What are the practical
>>implications of that apparently rather fine distinction? Well,
>>a neat example here is that the filthy-lucre activities of Anne
>>and Lynne are hidden from those who have access only to the more
>>abstract and perhaps more anodyne facts.
>
> Well, sure, but that is trivial and does not require dividing Anne into
> parts. (026)
ditto, as above. And I trust it wasn't quite as bad as dividing into
parts! Anyway, I hope my addendum on the lack of an official source
format laid that apparent syntactic spook to rest? (027)
>
>>
>>
>>Much less obviously still, though, is that detailed
>>MACK-AOS-driven processing within any one stream or thread
>
> What do you mean by 'stream or thread' here? (028)
Plain flows of processing which can be seen in technical or thread-like
terms or in more application-oriented ways, as in workflows. I was trying
to be non-specific, but the drift was towards the major differences
between RDF and MACK which I sketch below. (029)
>
>>
>>Now it is surely true that Pat or Chris or any one of the rest
>>of you logicians could easily render all of the above examples
>>into IKL or whatever other more usual symbolic-logical form you
>>choose, and in about half a minute flat.
>
> So far it seems to just be RDF in a different notation, insofaras I
> can follow it at all. (030)
Ha, not at all! (031)
Some brief high-level and doubtless ignorantly biased 'comparing
and contrasting' between MACK and RDF might help set the scene,
even though I haven't provided many MACK details yet. (032)
Obviously, both are ER-based so there is a lot in common. I am
reasonably sure that it would be easy to send any RDF into a
MACK environment while also preserving its semantics. But the
converse is certainly not the case. The most obvious reason is
that there is often a lot more flesh on a MACK application's
semantic net skeleton (A big further metaphor will expand on
that later), and it would typically be coded in a procedural
language. The AOS is already 100% canonically structured
accordingly. Most of it is available for canonical reuse by
applications. And applications can include their own too. (I
am talking now of the AOS as designed, but there is some significant
building up to it in the Metaset coding already.) (033)
A more global difference (in overall shape now, rather than mere
flesh on skeleton) is in how Forms are composed into components
of very variable granularity, in how reuse takes place, and much
more interestingly, in how all processing takes place. But then
that is what you would expect of a system for full application
development. (034)
So to be brutally frank, looking at what people seem to do with
RDF they haven't exploited a fraction of the potential of the ER
family yet. In its vision, RDF is still where we were with the
triple-entity fact 20 years ago and even demonstrated in 1988,
online to our national videotex network. And I don't think the
MACK features RDF lacks can remotely feasibly be grafted on to
it. (035)
You might tend to agree after you have heard more of the other
two pillars which I still have to expand on. (036)
I look forward to your reaction! (037)
Meanwhile, thanks again for your trouble here. (038)
Christopher
>
> Pat (039)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (040)
|