- From: Sebastian Samaruga <ssamarug@gmail.com>
- Date: Sun, 4 Aug 2019 17:34:09 -0300
- To: W3C Semantic Web IG <semantic-web@w3.org>, public-aikr@w3.org, public-rww <public-rww@w3.org>
- Message-ID: <CAOLUXBs=Z7TWY4Sud7HzEWAjsRM0AubgtvU3ojtS3oeAGALkaA@mail.gmail.com>
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 Sunday, 4 August 2019 20:39:20 UTC