Re: Search

Model of what? There are domain models that are defined as ontologies: for
social networks, genes, books etc etc. And few general ones like schema.org.
Some hypothetical “model of anything/everything” is neither possible nor
required.

I’m telling you what is already implemented and works, and you keep pushing
some vague descriptions like “semiotic”. Why haven’t you implemented it
then?

Just concentrate on learning to develop with/for Linked Data and SPARQL.
Forget all the hypothetical meta crap.

On Mon, 5 Aug 2019 at 19.21, Sebastian Samaruga <ssamarug@gmail.com> wrote:

> 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.
>> >> >
>>
>