- From: Sebastian S. <cognescent@gmail.com>
- Date: Tue, 25 Sep 2012 19:03:26 -0300
- To: semantic-web@w3.org, pragmaticweb@lists.spline.inf.fu-berlin.de, topicmapmail@infoloom.com
- Message-ID: <CAFnmbpUbou46H4SZFP027_9xzDpV+kVyntp=8vHG1Ddh+pSY1A@mail.gmail.com>
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.
Received on Tuesday, 25 September 2012 22:07:50 UTC