Hi Linas,

Tx for taking the time to reply.

On Sunday, February 18, 2018 at 8:38:28 PM UTC+1, linas wrote:
> Hi Amirouche, 
> I skimmed th PDF's.  Some of the goals are laudable: I quote: 
> "the exchange of partial graphs, personalised views on data 
> and a need for trust. A strong versioning model supported by 
> provenance". 
> So, at a meta-level, yes.  In practice, a triple-store strikes me as 
> worthless, pointless, hopeless.  Perhaps I am wrong -- I would love 
> it if someone explained it to me.  So from the PDF: 
> ":Adam :knows :Bob" 
> Great. Who? Fat Bob or skinny Bob?  Did you mean Robert? Robert, 
> like the guy down the hall, or Robert, the salesman who visits every 
> Tuesday?  Are you 100% certain about that? Or are you just guessing? 

Bob is an identifier. It can actually Fat Bob or skinny Bob, it depends 
what other
triples are associated with Bob.

> In my personal experience, triples are wholly inadequate to deal with 
> knowledge representation of the above form.  If I'm wrong, let me know 
> how. 

RDF triple stores represents graph or multiple graphs. The difference in 
of storage between a triple store and a property graph is that a triple 
store put
emphasize on edges. That is, they store and query *labeled edges* called 

For instance:

    Bob knows Alice

Is a representation of the *directed edge* between the node called "*Bob*" 
and and the 
node called "*Alice*" with a label "*knows*". In particular, in a triple 
store, node properties
are represented as edges too *ie.* triples which sounds counter intuitive 
compared to 
the property graph approach where you *store on disk* all properties of a 
node with the node itself
a link it to incoming and outgoing edges, and similarly for edges, hence 
the linked-list
storage approach. In triple store, a triple is decomposed into:

   Subject Predicate Object

They are stored together. 

An advanced triple store (like datomic) doesn't assume something particular 
about the
Object (called Value in datomic) in terms of indexing until you specify it 
in the schema,
see this particular paragraph in datomic documentation 
<https://docs.datomic.com/on-prem/indexes.html#avet>. Similarly and 
depending on
a schema you can define a particular predicate (or set of predicates) to be 
indexed in particular fashion (see fulltext eventual indexing in datomic) 
or spatiotemporal
indexing or whatever.

You can have an infinite set of predicate (hence an infinite set of 
properties in terms of property graph),
because the *query engine streams everything*.

Datomic is actually a versionned triple store with linear history except it 
claim conformance with RDF standards (for good reason because many think 
EAV and
RDF are failures). AFAIU the implementation of a triple store use the same 
described in this (new) documents:

- https://docs.datomic.com/on-prem/indexes.html
- https://docs.datomic.com/on-prem/schema.html

> The atomspace was designed to hold arbitrary expressions, like "Adam knows 
> Bob, the curly-haired, fat and always-smiling Bob, and I know this because 
> Carol overheard it while standing in line at the cafeteria for lunch. So 
> I'm 98% 
> certain that Adam knows Bob."

That is also possible in a triple store. In property graph you reify 
as multiple vertices and edges, using a similar technique in triples stores 
to express 
something about a particular triple. 

It's clear to me that you can do the same thing with triple stores and 
property graph,
except triples don't assume all properties of given node can stay in RAM. 
That was
not my question.

> Should the atomspace also include some default model for exchange of 
> partial graphs, versioning and provenance?  Maybe. So far, we have little 
> or no experience with any of this - no one has needed or asked for this, 
> so I cannot guess if our current infrastructure is adequate, or if we need 
> yet more.  In a certain sense, versioning and provenance is already 
> built into the atomspace, in a "strong" way. But no one uses it. 

That's the heart of my question. Seems like the answer is simply: no.

Basically, what I wanted to know as *a scientist working with loads of 
*data*, *do you feel the need to share and version in multiple branches 
structured data to*
*do your work*. My take on this would have been "yes" because for instance
this thread makes me think of that “Preloading atomspace with initial data 
<https://groups.google.com/forum/#!topic/opencog/jB7N-WV3wOs>” where
you explain that the best way to go, is to dump postgresql.

I have other use cases, in mind like *IF *(big if, I don't say that's what 
should be done)
link grammar's and relex dictionaries were stored in a versioned atomspace, 
it would
be easier (I think) to test new grammars... But today, the current workflow 
is good enough
for those cases because the grammars are rather small and stay in RAM. 

BUT (another big) if AGI projects rely more on more on *curated* structured 
databases statistically
built that are bigger than RAM ie. imagine wikidata put together out of 
unstructured text *that must be edited*, 
then I think a versioned atomspace and proper tooling makes sens (that is a 
tool like wikibase).

That said, like you say it's already possible for you to use the atomspace 
to version data and use branches.

*My question: is versioning and branching bigger than ram structured data 
part of your workflow?*

Just to be clear: I am not anymore planning to replace atomspace anytime 
soon. You invested too much
in the atomspace and are moving toward more integration with the atomspace 
that it makes that 
unimaginable. Also, the only improvement would be easier workflows instead 
for instance of dumping
the atomspace in wikibase, editing it there, and dumping it again and 
loading it in atomspace which is not
a workflow that is in current practice AFAIK. (also wikibase is not a good 
tool to edit arbitrary graphs)

Best regards

You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to