[PragmaticWeb] Could this work?

[Sebastian S.]

Hi, hope someone could help, need some orientation and ask given this lists
helped me in the past. I still trying to figure out how to build knowledge
- semantic applications. Sorry if I still looking very inexperienced, need
to share this because I'm trying to build an application and I would like
not to seem trying to reinvent the wheel.

The idea is to provide an inter-operable solution providing an abstraction
level over what could be any data-source from heterogeneous sources and
being able to enhance with a platform for analysis, mining, big data (BI),
integration and inter-operation of systems based on standard
representations (could be ISO 15926) and lastly being able to utilize the
tool as an application development platform, provided on the services that
where previously integrated.

One idea for such attempt would be to have what could be called 'CUPs' (or
Common Upper Profile) which encapsulate the abstraction level needed for
handling many, diverse, data origins. A CUP could be an 'arrangement' of
how the knowledge from other application/sources should be viewed in order
to inter-operate between diverse CUP Profiles (DS Providers). In the
beginning a CUP could be a mapping from an underlying data store (perhaps
triples) into an ontological view. CUP interaction between providers should
enable to 'augment' data itself and to 'activate' roles (or behavior) when
its possible given a context.

CUPs can lastly 'recognize' data and enable those augmentations and
activations of knowledge and information given whatever data-sources it
could 'read'. The point for achieve such a goal here is to have an
algorithmic view of the ontology. One first such CUP could be what can be
called a 'situation' view. The concepts of this cups will be: A Situation
where Subjects plays Roles, A Role which occurs given a Subject and a
Situation and Subjects, which participate in Situation given Roles. Note:
this could be whatever we want to look at an underlying source as, the
concepts here are only illustrative for the description of a solution.

Not being an expert in functional programming, I've found that there is a
'functional' relation, in the form of a triple, between this concepts. And
I've found that the relationship holds even when considering what I call
other CUPs (ie.: Rules, Behavior, etc) treated in the same way. Also I've
found there is a design pattern in the functional world that would enable
me treating different CUPs and different CUP parts in an homogeneous
programmatic manner. Again, I'm not an expert and I'm scratching my head
around this. The pattern is called Monad(s) and it design for me is such an
issue.

I think, what if I possibly could abstract this CUP pattern, given the
functionality provided by a Monad / Monadic framework, and use it
correctly  given the type constructors for this domain and a well defined
domain of 'general' functions. Could this give me the possibility to
arrange resources (URI Web resources) wrapped uniformly into their monadic
types, to solve in an 'algorithmic' manner the issues related with CUP
mappings/merge and/or services for querying and analyzing data?

The intuition tells me it is possible. What if I arrange my CUP types into
their corresponding ADTs and use the lattice their forms to see where it is
possible to 'calculate' solutions given the concepts under consideration.
My first attempt is to draw a lattice, given the following types:

.X = A x B (Occurrence)
.Y = B x C (Participation)
.Z = C x A (Player)

.A = List<Y> (Subject)
.B = List<Z> (Situation)
.C = List<X> (Role)

.A'(B) = A x Y (Kind of Situation)
.B'(C) = B x Z (Kind of Role)
.C'(A) = C x X (Kind of Subject)

There is also a
diagram<http://cognescent.googlecode.com/files/Lattice1.png>showing
this arrangement. What a I meant is, for a CUP, considering these
'functional' aspects, one could treat an ontology, ie., LOD, as a series of
Subjects occurring in Roles in given Situation, or whatever consideration
where necessary for the domain in hand. And given that monads allows for
the definition of a domain in where monadic types are subject of function
application, these functions could be in the upper ontology too, being
knowledge (augmenting, activation) functions over the (inter-operable)
datasets.

The question for this being algorithmically 'calculable' could be resolved
if one could assign identifiers to concepts that fall into the lattice (see
Diagram). For example, given a formalism where we use a tree segment
identifier where the first segment identifies an A (Subject), the second
segment identifier a B (Situation) and the third segment identifies a C
(Role) then we could have an Occurrence identifier (X) as the first two
segments 'populated' with some Subject and Situation identifiers. Lastly
this could be 'recursive' treating an A' as a B (Situation) and 'embedding'
the three segments only in the first. The identifier could be anything from
a bit string (maybe ternary to allow partial matches) or a prime number
thus expressing composition by multiplying parts identifiers.

The diagram <http://cognescent.googlecode.com/files/Lattice1.png> lattice
could also be regarded as having levels (much as of those in meta modeling,
ie., MOF) in which the upper levels are least specific and the lower levels
are more specific (or instances) for example for a particular Situation
happening/happened for a particular subject.

Regards,
Sebastian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spline.inf.fu-berlin.de/pipermail/pragmaticweb/attachments/20120925/44ec3980/attachment.html>