A Fórum-Tudomány-filozófikus programozás/minden adatbázis témakörben a 67.hozzászólás környékén AndrisK is eljutott addig, hogy egy objektumnak elég a SET() és GET() metódus, és ezzel "minden" lekezelhető.
Én ezt egészíteném ki - a még ismeretlen nevű - "ön help"-el. (Meg még azzal, ami feltétlenül fontos lehet.) De mondhattam volna úgy is, hogy elég csak az "ön help", mert ő meg tudja mondani, hogy milyen további metódusok és változók konstansok meg mifenék érhetőek el kintről. Így meg tudja adni a Set(), a Get() létezéseit is.
A hogyan tegye ezt? : kérdésre megfelelő megoldás lehet az XML. (de az is lehet, hogy nem kell ilyen messzire elmenni)
A mit kell hirdetni? : kérdésre várom a további javaslatokat. Esetleg elkezdhetjük megbeszélni azt, hogy mire szeretném használni. Vagyis a következő lépésből (céljainak megfelelően) próbáljuk meg definiálni ezt a szintet.
Nálam irányadó szempont az un: dinamikus metódusú objektumok kezelhetőségének elérése. Az amikor egy objektum látható felülete nem állandó, hanem változó és ezáltal metódusok és konstansok jelenhetnek meg illetve tünetnek el. Ennek a témának a rövidre zárásához egy sorszámmal szeretném azonosíttatni a felületet és innentől minden mehet tovább.
(Az lehet hogy ez most túl nagy ugrás, de: ) Annyi azonban látszik - a "mit kell hirdetni"-ből -, hogy - bármit is mondok - azt valamihez kötni kell. Ezt a láncot továbbfolytatva eljutunk az axiómákhoz. Tehát én a be épüléskori információcserét egy axióma verziószám és felület állapotszám lekéréssel kezdeném.
Utána a típusok leírásait is melyek az axiómákból építkeznének. Mivel a típusok nincsenek nagyon messze az alap axiómáktól ezért is tehetem meg a fenti kijelentést. Bár az eddig ismert (használt) típusok is lehetnek axiómák (nekem mind1). Ami fontos az az, hogy az axiómakörnek mindenféleképpen nyitottnak kel lennie a bővíthetőségre.
Utána a gyakorlatban már elterjedt, - eddig is megjelenő - adatokat hirdetném (propagálnám) továbbra is.
-Ezeket az alap meghatározásokat fel kéne építeni, hogy a módszert megtanulva tovább lehessen lépni a bonyolultabb fogalmak felé. . . . csíszta XML, csak nem ugyan arról a bázispontról.-
Legvégül pedig a folyamatokról a használhatóságról adnék valamit.

A tartalom még nagyon nyitott kérdés. Egy kis segédlet hozzá.
Az idő definíciója témakörből.  . A 7. Hozzászólásából: "Boltzmann szerint egyébként a fizikai akármik definícióját tökéletesen helyettesíti mérésük megadásának mikéntje. " Egy kicsit igazítva rajta én azt mondanám, hogy nem fontos mindent definiálnunk, elég lehet az is ha meg tudjuk mondani a pontos használatát.

E "tervezgetés" során igazolást szeretnék kapni arra, hogy egy-egy fogalom definíciója nem más, mint a kapcsolatrendszere (Vagyis az, ami megmondja azt, hogy milyen a viszonya egy másik fogalomhoz 6és fordítva). Itt egy kicsit el kellene gondolkodni azon, hogy mikor mondjuk valamire azt, hogy: értem.

Egy kis kitérő: Az axiómarendszer adhat lehetőséget arra, hogy az ASIMOV féle robotok alaptörvényi mindig szem előtt legyenek. (HW-be égetném! Reakciókat az AI-s topicba?)

Axiómáknak titulálom
:érték: igen, nem, hely, cím, adat, bármi, üres, bit0, bit1, azonosító, lista, szeparátor, érték, típus, objektum
:művelet: NOT, egy, művelet, eleme, címzés, cél(ja), mindig, soha, állandóság, változás, előtte, utána, értéke, tud(képes), lehet, van, be, ki, ismétlés
:kapcsolat (2 érték közt egy művelet, avagy N3, mint az XML-nél) :
igen-not-nem, not-egy-művelet, eleme-egy-művelet, címzés egy művelet, eleme-not-egy, igen-egy-adat, nem-egy-adat, hely-egy-adat, igen-not-nem, stb…
:használat: Nos ez még kérdéses. Önállóan legyenek felsorolva, vagy az állításokkal (kapcsolatokkal) egyszerre 4. "Paraméterként"?

Szükség lesz az következő fogalmakra is, melyekkel nem tudok mit kezdeni: mutatás, futás, átminősítés, ismétlődés, értékrend, igazságtábla, cselekvés.
Fura dolgok:
Az állításokban minden egyes kötés: művelet, a végpontok pedig adatok? Minden Művelet (programot és ezáltal ) futtatható kódot is takar?
Kapcsolat rendszer + folyamatleírások. Ez most program vagy nem program?

Szeretném ismertetni, hogy én üzenettovábbításos "tüzelésű" objektumokban gondolkodom és a régi folyamatelvnek megfelelően INP-MŰV-OUTP sémának megfelelően. Valamint homályos az egymásba ágyazás és láncolás problémaköre.

. . . hopp. Itt már szétestem. Elfogyott a rend. Most már csak kirakós darabkáim vannak, no meg ráérzések. Kérlek benneteket segítsetek.

Annyi még látszik, hogy: Az ontológiai definíciók (az adatok és a műveletek) később elhagyhatóak, amennyiben kellően teljessé tud válni a szemantikai leíráshalmaz (állítások halmaza=relációk halmaza)
Továbbá az, hogy a szemantikai hálón haladva (mint programon) ami megmondja azt, hogy milyen adatunk legyen és mit csináljunk vele, ezáltal objektumok építhetőek fel, amik alkalmasak lesznek AndrisK SQL szerű lekérdezéseire. Jéé ez . . . csísztára olyan mint a DNS. Az állításban szereplő műveletek a fehérjék (nanorobotok) és egymás után alkalmazva őket előállítanak valamit (RNS-t).

Kiegészítés a robotos példámhoz: Az n3-ban szerepelhet olyan sor, hogy "te-képes_vagy-mozogni". Ez jelentheti azt, hogy használhatja a céljainak elérésére, és az új eszköz mozgatja őt. Bár ez utóbbi mondatot is "át" lehet neki adni. (XYZ_eszköz-mozgat-téged.)
A fentieket egy kicsit végiggondolva belátható, hogy teljesen mindegy, hogy Előre(),Hátra(),Balra(),Jobbra() metódusokon keresztül lehet vezérelni, vagy a SetSebesség() és SetIrány() pozitív és negatív értékeivel, mert a leírások (relációik felsorolása) során kapcsolatba kerülnek a 3Dhely-el, és a mozgás fogalmakkal.

Kedves despil_hun !
Úgy fest, hogy ilyen irányba hald(ok)unk. Vigasztalásként: a megoldási mintákat lehet, hogy nekünk kell majd megadni neki. Én még nem láttam be azt, hogy kreatív lesz.