Re: Could this work?
"Sebastian S." <[email protected]> Thu, 27 Sep 2012 17:45:20 -0300
| Newsgroups | gmane.text.xml.xtm.general |
|---|---|
| Message-ID | <CAFnmbpV5fCPitKF+ik_FjqVKqVYMD8GsKyYFPOyMuofVv30TRA@mail.gmail.com> |
--===============5666625447224434421== Content-Type: multipart/alternative; boundary=20cf3071c81e7ed0f904cab50431 --20cf3071c81e7ed0f904cab50431 Content-Type: text/plain; charset=ISO-8859-1 Nathan, I'll try to explain better. And I'll be reading the links you brought. On Thu, Sep 27, 2012 at 1:58 PM, Nathan <[email protected]> wrote: > Yes, it could work :) > > I'd encourage you to look at: > Computational REST: http://www.erenkrantz.com/**CREST/<http://www.erenkrantz.com/CREST/> > NetKernel: http://www.1060research.com/**netkernel/<http://www.1060research.com/netkernel/> > Stardog: http://stardog.com/ > Notation 3 and SWAP: http://www.w3.org/2000/10/**swap/doc/<http://www.w3.org/2000/10/swap/doc/> > RIF: http://en.wikipedia.org/wiki/**Rule_Interchange_Format<http://en.wikipedia.org/wiki/Rule_Interchange_Format> > > and also to define any custom terminology ou use, such as "Situation". > Dummy example: Situation example = Medical examination. Role example = Doctor, Patient, Diagnose Subject example = Person (doctor or patient), Disease (diagnose). Those are the 'lens' I'm interested in when analyzing and / or recognizing data in a CUP manner. Maybe another CUP / Profile would like to see this same view of the underlying data as a service provider / consumer view, maybe for billing purposes. There is when the 'activation' and 'augmentation' would come into play contextually. The CUP schema / instances are to be recognized at different levels, from form-specification to instance data (proper situations). This is going to be done via mappings / inference at the triple store level. > Finally, the only detail that worries me, is the CUP approach, it seems > very much like a common upper ontology, which would be virtually impossible > to define - so instead it may be useful to consider the format of mappings, > and have those as the pivotal enabler for the full system. Users provide > maps of their data to and from common ontologies, and then integration is > much simpler. > As I meant this, 'CUPs' are more like form mapping purposes of the views I'm interested in about underlying ontologies of the same data. That's why I need a uniform (functional) way of treating resources and I'm investigating if this could be done in, ie.: Scala with design patterns or Monads. I would like, for example, say something with this and that is a Situation, and then the specialized kind of situation, regardless of forcing for an upper ontology but using 'Profiles'. > Also, do consider proxie vocabularies/ontologies - mapping up common > properties between different ontologies, and providing them all in a single > new ontology which proxies, or aliases, the older existing ontologies. > Fundamentally I think this could be achieved using an approach similar of what it is proposed by ISO 15926 Part 2 and part 4. > I'm especially interested in the monadic computation approach you're > considering, I believe there's a lot of scope here, see the CREST paper > above. > Right now I began reading 'Pro Scala: Monadic Design Patterns for the Web' by L.G. Meredith and it seems a very reasonable approach to utilize what is mentioned there as a starting point once I've grasped all the concepts in the book. I share the view of an application being driven by a domain abstract syntax much in a DSL fashion. What I need to realize from here is the architecture. Once I get a working model for the level of knowledge asset management I want, next is to decide where to put each part. Model (persistence, DSL abstract syntax), REST layer and an MVC (functional) protocol to handle concrete representations. And maybe a service layer to leverage all the other components. Best, Sebastian. > Best, > > Nathan > > Sebastian S. wrote: > >> 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<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<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. >> >> > --20cf3071c81e7ed0f904cab50431 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Nathan, I'll try to explain better. And I'll be reading the links y= ou brought.<br><br><div class=3D"gmail_quote">On Thu, Sep 27, 2012 at 1:58 = PM, Nathan <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Yes, it could work :)<br> <br> I'd encourage you to look at:<br> Computational REST: <a href=3D"http://www.erenkrantz.com/CREST/" target=3D"= _blank">http://www.erenkrantz.com/<u></u>CREST/</a><br> NetKernel: <a href=3D"http://www.1060research.com/netkernel/" target=3D"_bl= ank">http://www.1060research.com/<u></u>netkernel/</a><br> Stardog: <a href=3D"http://stardog.com/" target=3D"_blank">http://stardog.c= om/</a><br> Notation 3 and SWAP: <a href=3D"http://www.w3.org/2000/10/swap/doc/" target= =3D"_blank">http://www.w3.org/2000/10/<u></u>swap/doc/</a><br> RIF: <a href=3D"http://en.wikipedia.org/wiki/Rule_Interchange_Format" targe= t=3D"_blank">http://en.wikipedia.org/wiki/<u></u>Rule_Interchange_Format</a= ><br> <br> and also to define any custom terminology ou use, such as "Situation&q= uot;.<br></blockquote><div><br>Dummy example:<br>Situation example =3D Medi= cal examination.<br>Role example =3D Doctor, Patient, Diagnose<br>Subject e= xample =3D Person (doctor or patient), Disease (diagnose). <br> <br>Those are the 'lens' I'm interested in when analyzing and /= or recognizing data in a CUP manner. Maybe another CUP / Profile would lik= e to see this same view of the underlying data as a service provider / cons= umer view, maybe for billing purposes. There is when the 'activation= 9; and 'augmentation' would come into play contextually. The CUP sc= hema / instances are to be recognized at different levels, from form-specif= ication to instance data (proper situations). This is going to be done via = mappings / inference at the triple store level.<br> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8= ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> Finally, the only detail that worries me, is the CUP approach, it seems ver= y much like a common upper ontology, which would be virtually impossible to= define - so instead it may be useful to consider the format of mappings, a= nd have those as the pivotal enabler for the full system. Users provide map= s of their data to and from common ontologies, and then integration is much= simpler.<br> </blockquote><div>=A0</div><div>As I meant this, 'CUPs' are more li= ke form mapping purposes of the views I'm interested in about underlyin= g ontologies of the same data. That's why I need a uniform (functional)= way of treating resources and I'm investigating if this could be done = in, ie.: Scala with design patterns or Monads. I would like, for example, s= ay something with this and that is a Situation, and then the specialized ki= nd of situation, regardless of forcing for an upper ontology but using '= ;Profiles'.<br> </div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0= pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Also, do consider proxie vocabularies/ontologies - mapping up common proper= ties between different ontologies, and providing them all in a single new o= ntology which proxies, or aliases, the older existing ontologies.<br></bloc= kquote> <div><br>Fundamentally I think this could be achieved using an approach sim= ilar of what it is proposed by ISO 15926 Part 2 and part 4.<br><br></div><b= lockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-le= ft:1px solid rgb(204,204,204);padding-left:1ex"> <br> I'm especially interested in the monadic computation approach you'r= e considering, I believe there's a lot of scope here, see the CREST pap= er above.<br></blockquote><div><br>Right now I began reading 'Pro Scala= : Monadic Design Patterns for the Web' by L.G. Meredith and it seems a = very reasonable approach to utilize what is mentioned there as a starting p= oint once I've grasped all the concepts in the book. I share the view o= f an application being driven by a domain abstract syntax much in a DSL fas= hion. What I need to realize from here is the architecture. Once I get a wo= rking model for the level of knowledge asset management I want, next is to = decide where to put each part. Model (persistence, DSL abstract syntax), RE= ST layer and an MVC (functional) protocol to handle concrete representation= s.<br> <br>And maybe a service layer to leverage all the other components. Best,<b= r>Sebastian.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin= :0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"= > <br> Best,<br> <br> Nathan<br> <br> Sebastian S. wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div><div class=3D"h5"> Hi, hope someone could help, need some orientation and ask given this lists= <br> helped me in the past. I still trying to figure out how to build knowledge<= br> - semantic applications. Sorry if I still looking very inexperienced, need<= br> to share this because I'm trying to build an application and I would li= ke<br> not to seem trying to reinvent the wheel.<br> <br> The idea is to provide an inter-operable solution providing an abstraction<= br> level over what could be any data-source from heterogeneous sources and<br> being able to enhance with a platform for analysis, mining, big data (BI),<= br> integration and inter-operation of systems based on standard<br> representations (could be ISO 15926) and lastly being able to utilize the<b= r> tool as an application development platform, provided on the services that<= br> where previously integrated.<br> <br> One idea for such attempt would be to have what could be called 'CUPs&#= 39; (or<br> Common Upper Profile) which encapsulate the abstraction level needed for<br= > handling many, diverse, data origins. A CUP could be an 'arrangement= 9; of<br> how the knowledge from other application/sources should be viewed in order<= br> to inter-operate between diverse CUP Profiles (DS Providers). In the<br> beginning a CUP could be a mapping from an underlying data store (perhaps<b= r> triples) into an ontological view. CUP interaction between providers should= <br> enable to 'augment' data itself and to 'activate' roles (or= behavior) when<br> its possible given a context.<br> <br> CUPs can lastly 'recognize' data and enable those augmentations and= <br> activations of knowledge and information given whatever data-sources it<br> could 'read'. The point for achieve such a goal here is to have an<= br> algorithmic view of the ontology. One first such CUP could be what can be<b= r> called a 'situation' view. The concepts of this cups will be: A Sit= uation<br> where Subjects plays Roles, A Role which occurs given a Subject and a<br> Situation and Subjects, which participate in Situation given Roles. Note:<b= r> this could be whatever we want to look at an underlying source as, the<br> concepts here are only illustrative for the description of a solution.<br> <br> Not being an expert in functional programming, I've found that there is= a<br> 'functional' relation, in the form of a triple, between this concep= ts. And<br> I've found that the relationship holds even when considering what I cal= l<br> other CUPs (ie.: Rules, Behavior, etc) treated in the same way. Also I'= ve<br> found there is a design pattern in the functional world that would enable<b= r> me treating different CUPs and different CUP parts in an homogeneous<br> programmatic manner. Again, I'm not an expert and I'm scratching my= head<br> around this. The pattern is called Monad(s) and it design for me is such an= <br> issue.<br> <br> I think, what if I possibly could abstract this CUP pattern, given the<br> functionality provided by a Monad / Monadic framework, and use it<br> correctly =A0given the type constructors for this domain and a well defined= <br> domain of 'general' functions. Could this give me the possibility t= o<br> arrange resources (URI Web resources) wrapped uniformly into their monadic<= br> types, to solve in an 'algorithmic' manner the issues related with = CUP<br> mappings/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 into<= br> their corresponding ADTs and use the lattice their forms to see where it is= <br> possible to 'calculate' solutions given the concepts under consider= ation.<br> My first attempt is to draw a lattice, given the following types:<br> <br></div></div> ..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<Y> (Subject)<br> ..B =3D List<Z> (Situation)<br> ..C =3D List<X> (Role)<br> <br> ..A'(B) =3D A x Y (Kind of Situation)<br> ..B'(C) =3D B x Z (Kind of Role)<br> ..C'(A) =3D C x X (Kind of Subject)<br> <br> There is also a<br> diagram<<a href=3D"http://cognescent.googlecode.com/files/Lattice1.png" = target=3D"_blank">http://cognescent.<u></u>googlecode.com/files/Lattice1.<u= ></u>png</a>>showing<div class=3D"im"><br> this arrangement. What a I meant is, for a CUP, considering these<br> 'functional' aspects, one could treat an ontology, ie., LOD, as a s= eries of<br> Subjects occurring in Roles in given Situation, or whatever consideration<b= r> where necessary for the domain in hand. And given that monads allows for<br= > the definition of a domain in where monadic types are subject of function<b= r> application, these functions could be in the upper ontology too, being<br> knowledge (augmenting, activation) functions over the (inter-operable)<br> datasets.<br> <br> The question for this being algorithmically 'calculable' could be r= esolved<br> if one could assign identifiers to concepts that fall into the lattice (see= <br> Diagram). For example, given a formalism where we use a tree segment<br> identifier where the first segment identifies an A (Subject), the second<br= > segment identifier a B (Situation) and the third segment identifies a C<br> (Role) then we could have an Occurrence identifier (X) as the first two<br> segments 'populated' with some Subject and Situation identifiers. L= astly<br> this could be 'recursive' treating an A' as a B (Situation) and= 'embedding'<br> the three segments only in the first. The identifier could be anything from= <br> a bit string (maybe ternary to allow partial matches) or a prime number<br> thus expressing composition by multiplying parts identifiers.<br> <br></div> The diagram <<a href=3D"http://cognescent.googlecode.com/files/Lattice1.= png" target=3D"_blank">http://cognescent.googlecode.<u></u>com/files/Lattic= e1.png</a>> lattice<div class=3D"im"><br> could also be regarded as having levels (much as of those in meta modeling,= <br> ie., MOF) in which the upper levels are least specific and the lower levels= <br> are more specific (or instances) for example for a particular Situation<br> happening/happened for a particular subject.<br> <br> Regards,<br> Sebastian.<br> <br> </div></blockquote> <br> </blockquote></div><br> --20cf3071c81e7ed0f904cab50431-- --===============5666625447224434421== 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 --===============5666625447224434421==--