Could this work?

--===============3365300121809146820==
Content-Type: multipart/alternative; boundary=047d7b86c30e27eae304ca8de0b1

--047d7b86c30e27eae304ca8de0b1
Content-Type: text/plain; charset=ISO-8859-1

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.

--047d7b86c30e27eae304ca8de0b1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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&#39;m trying to build an application and I would l=
ike not to seem trying to reinvent the wheel. <br>
<br>The idea is to provide an inter-operable solution providing an abstract=
ion 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 representatio=
ns (could be ISO 15926) and lastly being able to utilize the tool as an app=
lication development platform, provided on the services that where previous=
ly integrated.<br>
<br>One idea for such attempt would be to have what could be called &#39;CU=
Ps&#39; (or Common Upper Profile) which encapsulate the abstraction level n=
eeded for handling many, diverse, data origins. A CUP could be an &#39;arra=
ngement&#39; 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 provide=
rs should enable to &#39;augment&#39; data itself and to &#39;activate&#39;=
 roles (or behavior) when its possible given a context.<br>
<br>CUPs can lastly &#39;recognize&#39; data and enable those augmentations=
 and activations of knowledge and information given whatever data-sources i=
t could &#39;read&#39;. The point for achieve such a goal here is to have a=
n algorithmic view of the ontology. One first such CUP could be what can be=
 called a &#39;situation&#39; view. The concepts of this cups will be: A Si=
tuation 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 co=
ncepts here are only illustrative for the description of a solution.<br>
<br>Not being an expert in functional programming, I&#39;ve found that ther=
e is a &#39;functional&#39; relation, in the form of a triple, between this=
 concepts. And I&#39;ve found that the relationship holds even when conside=
ring what I call other CUPs (ie.: Rules, Behavior, etc) treated in the same=
 way. Also I&#39;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&#39;m not an expert and I&#39;m =
scratching my head around this. The pattern is called Monad(s) and it desig=
n for me is such an issue.<br>
<br>I think, what if I possibly could abstract this CUP pattern, given the =
functionality provided by a Monad / Monadic framework, and use it correctly=
=A0 given the type constructors for this domain and a well defined domain o=
f &#39;general&#39; functions. Could this give me the possibility to arrang=
e resources (URI Web resources) wrapped uniformly into their monadic types,=
 to solve in an &#39;algorithmic&#39; manner the issues related with CUP ma=
ppings/merge and/or services for querying and analyzing data?<br>
<br>The intuition tells me it is possible. What if I arrange my CUP types i=
nto their corresponding ADTs and use the lattice their forms to see where i=
t is possible to &#39;calculate&#39; solutions given the concepts under con=
sideration. My first attempt is to draw a lattice, given the following type=
s:<br>
<br>.X =3D A x B (Occurrence)<br>.Y =3D B x C (Participation)<br>.Z =3D C x=
 A (Player)<br><br>.A =3D List&lt;Y&gt; (Subject)<br>.B =3D List&lt;Z&gt; (=
Situation)<br>.C =3D List&lt;X&gt; (Role)<br><br>.A&#39;(B) =3D A x Y (Kind=
 of Situation)<br>
.B&#39;(C) =3D B x Z (Kind of Role)<br>.C&#39;(A) =3D C x X (Kind of Subjec=
t)<br><br>There is also a <a href=3D"http://cognescent.googlecode.com/files=
/Lattice1.png">diagram</a> showing this arrangement. What a I meant is, for=
 a CUP, considering these &#39;functional&#39; aspects, one could treat an =
ontology, ie., LOD, as a series of Subjects occurring in Roles in given Sit=
uation, or whatever consideration where necessary for the domain in hand. A=
nd 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 ove=
r the (inter-operable) datasets.<br>
<br>The question for this being algorithmically &#39;calculable&#39; 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 s=
egment identifier where the first segment identifies an A (Subject), the se=
cond 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 s=
egments &#39;populated&#39; with some Subject and Situation identifiers. La=
stly this could be &#39;recursive&#39; treating an A&#39; as a B (Situation=
) and &#39;embedding&#39; the three segments only in the first. The identif=
ier could be anything from a bit string (maybe ternary to allow partial mat=
ches) or a prime number thus expressing composition by multiplying parts id=
entifiers.<br>
<br>The <a href=3D"http://cognescent.googlecode.com/files/Lattice1.png">dia=
gram</a> 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 an=
d the lower levels are more specific (or instances) for example for a parti=
cular Situation happening/happened for a particular subject.<br>
<br>Regards,<br>Sebastian.<br><br>

--047d7b86c30e27eae304ca8de0b1--

--===============3365300121809146820==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
topicmapmail mailing list
topicmapmail-Zo64W7twoUFWk0Htik3J/[email protected]
http://www.infoloom.com/mailman/listinfo/topicmapmail

--===============3365300121809146820==--