Re: Applications

Paola, I'll try to respond you inline:

On Mon, Apr 22, 2019, 1:30 AM Paola Di Maio <paoladimaio10@gmail.com> wrote:

> Sebastian
> thanks for sharing
> I understand better now
>
> The reason why we communicate research is often to clarity it to ourselves
> first, as well as to get it appreciated/rubbished by others. :-)
>
> I see two possible points of interest (correct if wrong)
> 1. the use of RDF  quads (this could demand a use case type of research
> method)
> *(how does this relate to the rest of the stuff?)*
>

I've initially tried to tackle the problem of ontology matching: identity
resolution between different 'names' meaning the same entity in some
context, using 'semiotic' (sign, concept, object) aggregation / relations
for that.

Then, my use of RDF quads developed into a form of (hierarchy layered)
object graph serialization mechanism. Then, the 'layers' mechanism showed
to allow some kind of hierarchical aggregation and allow to 'infer': data,
schema and behavior 'layers' of an application by inspecting its data CRUD
messages (plain CSPO statements).


> 2. the development of a new construct/mechanism/representation
> To me these two seem possibly distinct
>

In fact, this is what could happen when a functional / object oriented
implementation exists. My plan is to abstract URI 'Connectors' implementing
event driven sources / sink mechanisms (HTTP verbs wrapping a database, for
example) and having a Functional Resource abstraction which homologue
backends.


> For either or both, it would be good to understand the novelty, the
> benefits (what problem do es the novelty solve? as opposed to not using it,
> or using other approaches)
>

The principal outcome of this proposed approach is to enable developers for
having a suite of tools, kind of framework, for augmenting, extending or
creating applications.

This, having abstractions of much higher level of plain current RDF stores
APIs providing a set of pluggable components, like the ones existing for
other plataforms (Java EE, Spring, Drupal, etc.).

then you have to demonstrate your claim with some experiment or example
> you then need to validate the outcome of experiment of example
>

I'm currently far far away of having anything implemented in any platform.
Just documents. I've just uploaded 'Index3.docx' but it's just an index /
roadmap for previous scrapbook.

I'd really appreciate if someone can help me with the 'Introduction to RDF
Graphs, Triples, Quads' section.


> If you could draft a few paragraphs to address each of the points
> then you can put your work up for peer review, I like open peer reviews
> Maybe ask some academic on this list to pre-review
>
> The you can submit to some publication of your choice
>

I'm sorry if what I currently have is just a set of thoughts in an
scrapbook. Any kind of help will be greatly appreciated. As you said, I
share in the hope of clarify stuff.

Best Regards,
Sebastián.



>
> P
>
>
> On Sat, Apr 20, 2019 at 1:12 AM Sebastian Samaruga <ssamarug@gmail.com>
> wrote:
>
>> Paola,
>>
>> I'll try to answer to your questions inline. But first, let me tell you
>> that the links I've posted on my first mail have some updates (blog and
>> documents):
>>
>> https://github.com/snxama/scrapbook/blob/master/Index2.docx?raw=true
>>
>> https://github.com/snxama/scrapbook/blob/master/Application.docx?raw=true
>>
>> http://snxama.blogspot.com
>>
>>
>> On Thu, Apr 18, 2019, 11:30 PM Paola Di Maio <paoladimaio10@gmail.com>
>> wrote:
>>
>>> Sebastian
>>> thank a lot, I can see you speak geek  :-)
>>>
>>> Is it a new method that you are proposing?
>>> I would find useful to understand if you could highlight
>>> - how does it relate to mechanisms already in place (I suspect your
>>> approach builds and extends on  existing methods?)
>>>
>>
>> In facts, I'm planning to use RDF Quads in a non "canonical" way. Maybe
>> I'll be using a RDF store for local persistence and DIDs (Distributed
>> Identifiers) for decentralized persistence of a distributed network.
>>
>> https://w3c-ccg.github.io/did-spec/
>>
>> Given that one of my goals is to infer applications data / schema /
>> behavior from the raw statements they could produce or consume for being
>> able to match this ontologies (data / schema / behavior matchings) from
>> different sources / applications and provide a mechanism for integration,
>> I'd be using a set of "connector" URIs implementations (events sources /
>> sinks) implementing whatever protocols / back ends I'd like to "plug" in
>> the network.
>>
>> So, it builds and extends on existing methods as long as one could write
>> an URI connector for that method: databases, services, SPARQL endpoints,
>> etc.
>>
>> - the benefits (what does this approach do that existing approaches
>>> don't?)
>>>
>>
>> URI implementations (connectors) will provide mechanisms for synchronize
>> back ends / data sources with the augmented view of the interactions
>> performed with this framework and interacting directly with this framework
>> through API protocols will enable to declaratively build applications and
>> services on top and extending existing augmentations.
>>
>> - limitations
>>>
>>
>> As long as this is, almost now, only and analysis and design draft,
>> implementation concerns are of mayor importance.
>>
>> - examples of applications with some kind of evaluation of the benefits
>>> and limitations
>>>
>>
>> In one of the documents I've sent I describe a potential "social" Producs
>> And Services Community Exchange Network. Maybe SoLiD (solid.mit.edu) or
>> something similar could solve the "social" part. And goods exchange is to
>> be orchestrated by "smart" matching of requesters / offerers
>>
>> -  is this something you would want to publish as a concept or suggest
>>> for adoption by W3C or our working group in any way (if so say how you
>>> envisage)
>>>
>>
>> Yes, In the realm of programming and ontology design patterns.
>>
>>
>>> When you have this info I wonder if this could make a useful submission
>>> for our forthcoming special issue AIKR, and in general it is good to send
>>> stuff for peer review
>>> unless this is going to become a patent or something
>>>
>>
>> Think it could be. As long as I can make a clear and understandable
>> document of all this.
>>
>>
>>> PDM
>>>
>>> On Fri, Apr 19, 2019 at 3:14 AM Sebastian Samaruga <ssamarug@gmail.com>
>>> wrote:
>>>
>>>> Paola, thanks for the feedback.
>>>>
>>>> What my attempts are about where, in the beginning, to match different
>>>> URIs or identifiers which refer to the same entity (in different databases
>>>> / ontologies, for example) to perform some kind of "ontology matching"..
>>>>
>>>> Then I've tried to develop a mechanism for using RDF Quads for encoding
>>>> an object graph (and a layers class hierarchy) using Contexts to denote the
>>>> class of an instance, Subjects to denote class instances and attributes
>>>> (members) and values: Predicates / Objects.
>>>>
>>>> Quads are "reified" as Resource(s). Also, Resource is a functional
>>>> wrapper reactive and event driven of an URI. And an URI could be
>>>> implemented with whatever backend which could produce or consume events
>>>> (databases, services, etc.). Resource layers hierarchy (Context) is to be
>>>> implemented by an actor / role type object pattern.
>>>>
>>>> Then I've realized that some basic type inference could be performed
>>>> with, for example, aggregating Subjects with the same predicates (Subject
>>>> Kinds). Idem for Predicates, Objects and Contexts. I've also realized that
>>>> plain "facts" statements could be aggregated in the previously mentioned
>>>> class hierarchy to abstract further, from plain data, instance / class
>>>> layers of what I call data / schema / behavior layers. Higher layers (i.e.:
>>>> Behavior) "aggregate" lower layers.
>>>>
>>>> Layers shape is as follow:
>>>>
>>>> Resource : Functional URI wrapper.
>>>>
>>>> (Context : Resource, Occurrence : Resource, Attribute : Resource, Value
>>>> : Resource);
>>>>
>>>> Each layer abstract:
>>>>
>>>> Statement (data instance):
>>>>
>>>> (Statement, Occurrence, Attribute, Value);
>>>>
>>>> someOne buys someProduct;
>>>>
>>>>
>>>> Entity (data class):
>>>> (Entity, Statement, Occurrence, Attribute);
>>>> someBuyer, someProduct (Entity);
>>>>
>>>> Role (schema instance):
>>>> (Role, Entity, Statement, Occurrence);
>>>> Buyer, Product (Role);
>>>>
>>>> Class (schema class):
>>>> (Class, Role, Entity, Statement);
>>>> Person, Good (Class);
>>>>
>>>> Flow (behavior instance):
>>>> (Flow, Class, Role, Entity);
>>>> someBought (Flow);
>>>>
>>>> Behavior (behavior class):
>>>>
>>>> (Behavior, Flow, Class, Role);
>>>> Buy (Behavior);
>>>>
>>>> This "aggregations" are part of what I call "Augmentation(s)":
>>>> Aggregation, Alignment and Activation are ones of those, which are
>>>> functional transforms described declaratively in an object graph metamodel.
>>>> The act of applying an Augmentation implies one source Resource (context),
>>>> one template Resource (transform) and a resulting (set of) Resource(s)..
>>>>
>>>> One also could Augment Resource(s) in a functional manner, using
>>>> reactive event driven APIs so, for example applying "Person" class to
>>>> "Employee" role could shield a Resource set of people being working for
>>>> someone. The ultimate goal is to be able to "plug" as much "backends"
>>>> connectors as posible into distributed peers which exposes protocols / APIs
>>>> for knowledge driven hypermedia applications.
>>>>
>>>> Best Regards,
>>>> Sebastián.
>>>>
>>>>
>>>> On Sun, Apr 14, 2019, 9:48 PM Paola Di Maio <paola.dimaio@gmail.com>
>>>> wrote:
>>>>
>>>>> Sebastian
>>>>>
>>>>> thanks for the post  and for sharing your docs
>>>>> I have only briefly glanced through them - working on deadlines all
>>>>> the time -
>>>>> and it looks interesting.
>>>>> I think many of us struggle to be coherent and no, this forum primary
>>>>> goal is not  psychoanalysis although many of us could do with some :-)
>>>>>
>>>>> Sharing thoughts can help us better formulate questions
>>>>> \
>>>>> I would be grateful if you could explain a bit more of  what you are
>>>>> sharing with us, and what kind of input you d like to receive on the docs,
>>>>> or explain how these can contribute to the mission
>>>>>
>>>>> thank you,
>>>>>
>>>>> PDM
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Apr 12, 2019 at 2:43 AM Sebastian Samaruga <ssamarug@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Sorry if I dare to post my spare thoughts again in this lists. I
>>>>>> apologize but it is in the hope of sharing what comes into my writings
>>>>>> trying to look for someone with more knowledge to "validate" or to "guide"
>>>>>> my points of view.
>>>>>>
>>>>>> Going through my most recent attempts of having something concrete
>>>>>> for sharing in plain English I realize one mistake I'm committing: I'm
>>>>>> trying to describe combustion vehicles (Hypermedia Applications) saying
>>>>>> that petroleum exists (Semantic Intelligence).
>>>>>>
>>>>>> As long as my post are going I've just got a stack of (incoherent)
>>>>>> "analysis" documents as the result of my work. And I had only those until
>>>>>> now because I was stuck because of the previously mentioned mistake (ah,
>>>>>> and because of my Bipolar Disease maniac episodes...).
>>>>>>
>>>>>> So, I should try to describe applications instead and see how and
>>>>>> where fuel should burn properly inside a motion vehicle to generate
>>>>>> traction. Every semicolon I write is updated into my GitHub repository, so,
>>>>>> sorry if you browse that "scrapbook" and you don't find anything even
>>>>>> intelligible.
>>>>>>
>>>>>>
>>>>>> https://github.com/snxama/scrapbook/blob/master/Application.docx?raw=true
>>>>>>
>>>>>> There is a brief technical description work in progress document. For
>>>>>> now it just a list of statements about a potential backend. Session and
>>>>>> Inteteraction layers are not specified.
>>>>>>
>>>>>> https://github.com/snxama/scrapbook/blob/master/Index2.docx?raw=true
>>>>>>
>>>>>> Best Regards,
>>>>>> Sebastian Samaruga:
>>>>>> http://snxama.blogspot.com
>>>>>>
>>>>>>
>>>>
>>>> On Sun, Apr 14, 2019, 9:48 PM Paola Di Maio <paola.dimaio@gmail.com>
>>>> wrote:
>>>>
>>>>> Sebastian
>>>>>
>>>>> thanks for the post  and for sharing your docs
>>>>> I have only briefly glanced through them - working on deadlines all
>>>>> the time -
>>>>> and it looks interesting.
>>>>> I think many of us struggle to be coherent and no, this forum primary
>>>>> goal is not  psychoanalysis although many of us could do with some :-)
>>>>>
>>>>> Sharing thoughts can help us better formulate questions
>>>>> \
>>>>> I would be grateful if you could explain a bit more of  what you are
>>>>> sharing with us, and what kind of input you d like to receive on the docs,
>>>>> or explain how these can contribute to the mission
>>>>>
>>>>> thank you,
>>>>>
>>>>> PDM
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Apr 12, 2019 at 2:43 AM Sebastian Samaruga <ssamarug@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Sorry if I dare to post my spare thoughts again in this lists. I
>>>>>> apologize but it is in the hope of sharing what comes into my writings
>>>>>> trying to look for someone with more knowledge to "validate" or to "guide"
>>>>>> my points of view.
>>>>>>
>>>>>> Going through my most recent attempts of having something concrete
>>>>>> for sharing in plain English I realize one mistake I'm committing: I'm
>>>>>> trying to describe combustion vehicles (Hypermedia Applications) saying
>>>>>> that petroleum exists (Semantic Intelligence).
>>>>>>
>>>>>> As long as my post are going I've just got a stack of (incoherent)
>>>>>> "analysis" documents as the result of my work. And I had only those until
>>>>>> now because I was stuck because of the previously mentioned mistake (ah,
>>>>>> and because of my Bipolar Disease maniac episodes...).
>>>>>>
>>>>>> So, I should try to describe applications instead and see how and
>>>>>> where fuel should burn properly inside a motion vehicle to generate
>>>>>> traction. Every semicolon I write is updated into my GitHub repository, so,
>>>>>> sorry if you browse that "scrapbook" and you don't find anything even
>>>>>> intelligible.
>>>>>>
>>>>>>
>>>>>> https://github.com/snxama/scrapbook/blob/master/Application.docx?raw=true
>>>>>>
>>>>>> There is a brief technical description work in progress document. For
>>>>>> now it just a list of statements about a potential backend. Session and
>>>>>> Inteteraction layers are not specified.
>>>>>>
>>>>>> https://github.com/snxama/scrapbook/blob/master/Index2.docx?raw=true
>>>>>>
>>>>>> Best Regards,
>>>>>> Sebastian Samaruga:
>>>>>> http://snxama.blogspot.com
>>>>>>
>>>>>>