- From: Sebastian Samaruga <ssamarug@gmail.com>
- Date: Mon, 5 Aug 2019 14:21:01 -0300
- To: Martynas Jusevičius <martynas@atomgraph.com>, W3C Semantic Web IG <semantic-web@w3.org>, public-rww <public-rww@w3.org>, public-aikr@w3.org
- Message-ID: <CAOLUXBvOubQBNNwdXdQtBwAtoA28wPVaFCbPkt2hFF+DzxE87Q@mail.gmail.com>
OK. Thanks. Sorry for attaching this message to the thread but I have a question or two in which both of us will obviously disagree. And I'd would like a second opinion. On Mon, Aug 5, 2019, 12:39 PM Martynas Jusevičius <martynas@atomgraph.com> wrote: > You have to question first if the components you envision are required > in the real world. I do not think a meta-model is necessary. > Isn't it RDF (triples / quads model abstractions) a model for, let's say, ontologies (other models). Aren't upper ontologies models for other models too? Isn't the term metamodel referencing the "model of a model" abstraction we use all the time (think of the relational model "modelling" of a database schema "model"). > We extract data from cloud services, convert to RDF, align the > vocabularies and reconcile IDs using SPARQL. With the data in a > triplestore, we build APIs and end-user apps using our Linked Data > Templates-driven platform. > When I think about meta models I use the term more in the upper ontology sense, de aggregating statements to a root concepts layer (semiotic layer sense) and then encoding them into an aggregated augmentable model / schema / entity matching enabled model (layers) which in its lower layer is also "dimensional" aware, thus allowing to match different models entities and different entities "measures" (occurrences / roles / attributes). > All the projections and aggregations are done using SPARQL. > The proposed "metamodel" could ingest any triple and align it into a semiotic layer from which "upper aggregations" enables discovering of models entities matching and dimensional features and augmentations. The main objective is to have a functional / object oriented set of components and domain driven facades for knowledge behaviors. The notion of a small "component" library for a "real world" application could be something that could be plugged in, for example: http://stanbol.apache.org or http://servicemix.apache.org Regards, Sebastián. > On Mon, Aug 5, 2019 at 5:11 PM Sebastian Samaruga <ssamarug@gmail.com> > wrote: > > > > Martynas, > > > > Thanks for taking time and your response. I will be trying to understand > your project and see if I'm able to contribute to it due my skills. I'm > mostly a mildly seasoned Java / Web backend / frontend developer with > knowledge of relational databases and the usual Java / Enterprise set of > frameworks. I could send you my resume if you'd like. Please let me know > where could I start reading about your project. > > > > However I think we are talking about different (and maybe complementary) > things. All what I have to offer by now is the notion / concept of a > metamodel "component" with a set of reactive / event driven APIs for > offering a set of domain driven knowledge patterns. > > > > And this notion is very small, maybe just a library. The clash with > other people doing similar things occurs when I describe the "scaffolding" > for use cases which could take advantage of it. The case was, at best, that > when I told someone: metamodel, they came back to me telling that I should > describe "applications". > > > > So, if you'd like, I could try to share to you the basic core concepts > of all what I've done yet, and the "features" of this component: > Augmentations (Aggregations, Alignments, Activations). > > > > Best, > > Sebastián. > > > > > > On Mon, Aug 5, 2019, 6:53 AM Martynas Jusevičius <martynas@atomgraph.com> > wrote: > >> > >> Hey man, > >> > >> I think I've told you before we have a Linked Data server/client stack > >> that is very similar to what you describe. We also have RDF data > >> extractors from Google services, Slack, Atlassian etc. > >> > >> Are you willing to contribute to an existing project and create value > >> on top of our work, or do you want just keep emailing this stuff? > >> > >> What are your programming/data skills? > >> > >> On Sun, Aug 4, 2019 at 10:35 PM Sebastian Samaruga <ssamarug@gmail.com> > wrote: > >> > > >> > Hi, > >> > > >> > Apologize for using the lists this way. I'm a developer currently > seeking for job (freelance / semantic web development). > >> > > >> > Given that I'm posting this already, let me take advantage to include > a few words regarding a, maybe pretentious, idea for a project. Take it as > my last experience in my resume. > >> > > >> > I just began trying to put this into words and is not obvious if I'm > being clear. So, sorry if this is kind of fuzzy, any comments are welcome: > >> > > >> > The idea of the project is to "augment" an ESB for EAI platform and > to enable it allowing it to make "inferences" regarding which routes to > use, "discovering" sources / destinations of an event message(s) which then > it transforms / enriches according destination "semantics" and format(s). > >> > > >> > This featuring the exposure of a generic facade which allows to see > in an "homogeneous" view the applications or services and their data, > schema and behavior (actions) that could be integrated into the tool. > >> > > >> > Different integrated applications are enriched with this facade and > with the events that, given the inferred routes and transformations, > augments theirs data, schema and behaviors, invoking activities > corresponding to each destiny semantics. > >> > > >> > The idea, finally, began to resemble a generic application / frontend > / endpoint gateway. For now I have a blog and an ongoing yet to be built > repository: > >> > > >> > http://snxama.blogspot.com > >> > http://github.com/snxama/scrapbook > >> > > >> > Use Case: Goals App > >> > > >> > In the beginning I thought make something that enhances / augments, > for example, productivity apps such as Jira, Trello and others, integrating > them with other tools (Drive, for example) "annotating" semantic > relationships between documents / objects / activities in / of each tool > and other tools from which a "translation" could be made where an activity > in one implies behavior in another. > >> > > >> > (this list is a "fuzzy" draft, I should explain myself in each point): > >> > > >> > Goals App: purpose / goals / domain driven syndication of integrated > business / social / cloud application features. User / Groups / Roles > Purpose(s), Goal(s), Task(s) "intelligent" tracking oriented focus > providing an abstraction and integration layer of players process flows / > interactions and players process assets management and semantic > orchestration. > >> > > >> > Goals App: Semantically annotated gestures / interactions (contexts, > purposes messages / interactions / resources / content). Subject context > occurrence role attributes values (metaclass, class, instance, occurrences). > >> > > >> > Goals App: API Facade for rendering aggregated data roles in contexts > interactions topics / subjects assets (conceptual domain contexts axis / > state views / activations: Forms / Flows). Example: domain declared > Customer (actor / role), Product, Order, Purchase, Invoice, etc. topics / > subjects assets rendered in contexts (Sales Report, Expenses Report, etc. > embedded / linked dashboards). Wizards. > >> > > >> > Goals App: Browse / search / activate: history / relations / referrer > context / interaction / gestures roles traceability / (dialogs). Gestures / > interactions (actor / asset, actor / actor). Wizards. > >> > > >> > Goals App: Hypermedia contents APIs (embedded / embeddable resources: > Semantic contextual Wiki / Apache Stanbol / CMS: hypermedia augmentation, > knowledge / behavior maps). Integration: augmentation / sync backends / > apps. Extension: services / APIs. Annotate / augment link content. DAV > protocol (integration / extension facades). > >> > > >> > Low level Resource / Message / Context model / layers API. REST. > Render DOM Context / OGM Domain (model) instances: Restful Objects / Apache > Isis / HAL / GraphQL (meta / domains models endpoints) like APIs. Forms / > Flows MVC / DCI APIs (connectors / clients / adapters). > >> > > >> > Regards, > >> > Sebastian. > >> > >
Received on Monday, 5 August 2019 17:32:40 UTC