You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Gregg Wonderly <ge...@cox.net> on 2021/03/05 19:27:59 UTC

Serializing data in River

I don’t recall if we’ve talked about Google Protocol Buffers as another means of serialization.  This seems like something that could be investigated as a gateway to support for many other languages/platforms that already have such support.

https://developers.google.com/protocol-buffers <https://developers.google.com/protocol-buffers>


Gregg Wonderly

Re: Serializing data in River

Posted by "Jeremy R. Easton-Marks" <J....@gmail.com>.
This could be really interesting. Just thinking quickly I could see using
the JavaSpaces Primary(Master)-Worker being used. Where the Primary hands
out work for each of the workers to work on their part of the problem with
the primary being the integrator. As you mentioned getting a shared data
model representing the knowledge would be the difficult part and solutions
may be best done on a domain-specific basis.

Would something like the below work as a proof of concept?
*Problem Description*
Annotation of an image with multiple workers in which each worker is
specialized in a specific type of "recognition" (e.g., Dogs, People, Cars)

*Flow*
1) A Primary sends out the image data to each worker.
2) Each Worker analyzes the image for it's specific type of recognition.
3) Each Worker sends back the location and type of object it detects back
to the Primary
4) The Primary then analyzes the information and interprets the image

*Google Protocol-Buffer Portion*
- The Workers broadcast what they are capable of using a neutral format
- All data is sent in Google Protocol Buffer Format
- Individual Workers can translate the data into whatever language they run
- Workers send back data in a similar format to a Primary that can use in
its language

On Fri, Mar 12, 2021 at 3:30 PM Phillip Rhodes <mo...@gmail.com>
wrote:

> > Hi Phil,
> > Can you elaborate a little bit on how you use JavaSpaces in AI Blackboard
> > system space? I think having some examples might help us better flesh out
> > this idea. I am also just curious from a research perspective. :-)
>
> Only in a conceptual sense. I haven't written any code to this end
> yet. Not knowing how familiar anyone reading this post will be with
> the basic idea of Blackboard Systems (or even Tuple Spaces as far as
> that goes) I'll share these two links first:
>
> https://en.wikipedia.org/wiki/Blackboard_system
> https://en.wikipedia.org/wiki/Tuple_space
>
> So my interest is in using Java Spaces as the "shared space" where the
> "experts" (eg, "agents" in another vernacular) share information. The
> devil, of course, is in the details. One big "detail" is working out
> what the representation of "knowledge" put into the blackboard should
> be. Something really fine-grained like RDF style triples could be an
> option, but there are all sorts of knowledge representation languages.
> And that's assuming you  want something symbolic. An even deeper
> question gets into how you might integrate symbolic / sub-symbolic
> agents in a model like this. Unfortunately I have more questions than
> I do answers. But generally speaking, this kind of "stuff" is where a
> lot of my interest lies.
>
>
> Phil
>


-- 
Jeremy R. Easton-Marks

"être fort pour être utile"

Re: Serializing data in River

Posted by Phillip Rhodes <mo...@gmail.com>.
> Hi Phil,
> Can you elaborate a little bit on how you use JavaSpaces in AI Blackboard
> system space? I think having some examples might help us better flesh out
> this idea. I am also just curious from a research perspective. :-)

Only in a conceptual sense. I haven't written any code to this end
yet. Not knowing how familiar anyone reading this post will be with
the basic idea of Blackboard Systems (or even Tuple Spaces as far as
that goes) I'll share these two links first:

https://en.wikipedia.org/wiki/Blackboard_system
https://en.wikipedia.org/wiki/Tuple_space

So my interest is in using Java Spaces as the "shared space" where the
"experts" (eg, "agents" in another vernacular) share information. The
devil, of course, is in the details. One big "detail" is working out
what the representation of "knowledge" put into the blackboard should
be. Something really fine-grained like RDF style triples could be an
option, but there are all sorts of knowledge representation languages.
And that's assuming you  want something symbolic. An even deeper
question gets into how you might integrate symbolic / sub-symbolic
agents in a model like this. Unfortunately I have more questions than
I do answers. But generally speaking, this kind of "stuff" is where a
lot of my interest lies.


Phil

Re: Serializing data in River

Posted by "Jeremy R. Easton-Marks" <J....@gmail.com>.
Hi Phil,
Can you elaborate a little bit on how you use JavaSpaces in AI Blackboard
system space? I think having some examples might help us better flesh out
this idea. I am also just curious from a research perspective. :-)

On Sun, Mar 7, 2021 at 4:05 PM Phillip Rhodes <mo...@gmail.com>
wrote:

> On Sun, Mar 7, 2021 at 1:40 PM Bryan Thompson <br...@blazegraph.com>
> wrote:
> > I agree that making River relevant to non java ecosystems would be a good
> > idea.
>
> +1
>
> Just to share one anecdote, a lot of my interest in River relates to
> using the JavaSpaces stuff, and experimenting with Blackboard systems,
> with an eye towards applications in AI. And while a lot of my work is
> done on the JVM (Java/Groovy, mostly), the idea of being able to
> easily integrate a sub-system written in, say, Python or C++ or Julia
> or $WHATEVER, is very appealing.
>
> Phil
>


-- 
Jeremy R. Easton-Marks

"être fort pour être utile"

Re: Serializing data in River

Posted by Phillip Rhodes <mo...@gmail.com>.
On Sun, Mar 7, 2021 at 1:40 PM Bryan Thompson <br...@blazegraph.com> wrote:
> I agree that making River relevant to non java ecosystems would be a good
> idea.

+1

Just to share one anecdote, a lot of my interest in River relates to
using the JavaSpaces stuff, and experimenting with Blackboard systems,
with an eye towards applications in AI. And while a lot of my work is
done on the JVM (Java/Groovy, mostly), the idea of being able to
easily integrate a sub-system written in, say, Python or C++ or Julia
or $WHATEVER, is very appealing.

Phil

Re: Serializing data in River

Posted by Bryan Thompson <br...@blazegraph.com>.
I agree that making River relevant to non java ecosystems would be a good
idea.

On Sun, Mar 7, 2021 at 10:11 Jeremy R. Easton-Marks <
J.R.EastonMarks@gmail.com> wrote:

> I think this would be an interesting path to explore. I like the idea of
> being able to write in other languages. It could increase the
> approachability of River, especially in the IOT field.
>
> Would this mean completely abandoning the lookup service?
> How do you think we should explore this more?
>
> On Fri, Mar 5, 2021, 1:28 PM Gregg Wonderly <ge...@cox.net> wrote:
>
> > I don’t recall if we’ve talked about Google Protocol Buffers as another
> > means of serialization.  This seems like something that could be
> > investigated as a gateway to support for many other languages/platforms
> > that already have such support.
> >
> > https://developers.google.com/protocol-buffers <
> > https://developers.google.com/protocol-buffers>
> >
> >
> > Gregg Wonderly
>

Re: Serializing data in River

Posted by "Jeremy R. Easton-Marks" <J....@gmail.com>.
I think this would be an interesting path to explore. I like the idea of
being able to write in other languages. It could increase the
approachability of River, especially in the IOT field.

Would this mean completely abandoning the lookup service?
How do you think we should explore this more?

On Fri, Mar 5, 2021, 1:28 PM Gregg Wonderly <ge...@cox.net> wrote:

> I don’t recall if we’ve talked about Google Protocol Buffers as another
> means of serialization.  This seems like something that could be
> investigated as a gateway to support for many other languages/platforms
> that already have such support.
>
> https://developers.google.com/protocol-buffers <
> https://developers.google.com/protocol-buffers>
>
>
> Gregg Wonderly