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 terms 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 triples. 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 the 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 doesn't 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 technics 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 hyper-edges 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 structured* *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 email@example.com. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/36aefdb5-424c-4e24-a579-2c2571d2ff64%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.