degyves

In fact you can use XML, but not barebones XML. XML does not contain semantics, which is needed to achieve interoperability. So you should use some more specialized XML, namely, RDF/XML. Which of course will increase complexity to XML. You can use also JSON-LD, which is a more complex JSON bc it adds semantics.

Growing anywhere is not enough reason to use something. A lot of things are available anywhere but not all of these will be safe for your community. Sacred plants are more complex than the individual impact. It has consequences on your society and this is why its management is by law restricted to native nations.

I'm native indigenous from Oaxaca, Mexico, home of several sacred ceremonies with magic mushrooms and other plants from millennia. I'd like to share that our Native Nations do not give permission for scientific research of magic mushrooms outside our culture. This is not an egoistic stand, but it is for your own safety. Sacred plants on pharma and marketing industries hands will only create more damage than good. If you are interested to learn about sacred plants you must learn respect from native nations and come, live here and share for a time, then a request to research can be asked to the community.

That depends of which precise definition of consciouness you're talking about, which is a flame wars research field. But it is a consensus that consciouness is not equal to inteligence.

Some specific reason to not recommend it?

How "most advanced graph database" does not supports already standardized SPARQL query? Have you found anything wrong with standard SPARQL?

The most impressive to me, is to read only a single comment worried about the ecological impact and the sustainability

Just start with Apache Jena, standards based with RDF as the exchange format and SPARQL for the query language. Others solutions may use proprietary stuff for better vendor lock-in: This is completely up to you if you want that. But with Apache Jena you can change later to other KG databases. Also: Apache Jena is easy to work with, since it includes Fuseki to start directly using it as a web API.

https://jena.apache.org/ https://jena.apache.org/documentation/fuseki2/

Once you need "big data" for your personal Knowledge Graph, you can use other RDF stores, without vendor lock-in.

Even more, we're already there: US ONC Health IT and HL7 are currently on the FHIR standard, which is slowly integrating linked data principles. E.g. currently uses JSON-LD: https://www.healthit.gov/buzz-blog/interoperability/heat-wav...

Not only now Linked Data + RDF is even simpler and nicer to learn: There are currently more libraries to work with. Also it is more critical than ever for many industries.

Current solution for several issues related with electronic health records concluded to create the new standard, to use RDF and linked data, which solved most of the issues on the previous standard. See FHIR: https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperabili...

In fact, current linked data discussions seem to me that become relevant again because it is more clear now that we have been misusing/overusing/ bad REST, microservices architectures and GraphQL for some already analyzed and solved problems.

But, of course, for a single application which doesn't require interoperability, not requiring standardized data exchange formats, not requiring support for flexible data representation, Linked Data and RDF will be clearly unnecessary. But on time, the future of data interconnection plays on the side of Linked Data IMHO.

Until now, current attempts to create some Linked Data + RDF alternate infraestructures are more likely to create ad-hoc, informally specified, bug-ridden, slow implementations of Linked Data and RDF.

SPARQL results DO have an inherent structure. Even more, this is why projects like Eclipse Lyo can automatically convert SPARQL results directly to Java Objects. So no, SPARQL it is not intended to be used directly but as a product for a library to be converted into objects or rows or graphs or anything the client needs.

On the other hand, GraphQL pushes its complexity (to worry about the "how") into the server's implementation. The complexity is still there. And it's impossible to be automatically browseable.

Semantic Web is only an application of SPARQL, not the only one.

Yeah, if you are writing HATEOAS APIs just by personal preference then you are using the wrong technology. You should write HATEOAS to make sure your API will be consistent, standard and automatically browsable on the long term.

Funny that ultra-large-enterprise crap could be applied to Facebook and GraphQL?

Oh yeah, GraphQL is backed by Facebook (may that be a hint of its momentum, like its support for React?) , unlike SPARQL which is a _standard_. You can also convert from PostgreSQL, MySQL, DB/2 and others to SPARQL. Still, only difference seems 1. Facebook pushing its non-standardized tech around and 2. Losing any benefits from HATEOAS from the usage of GraphQL.

I think you should read it directly from the website: "GraphQL is a query language for your API, and a server-side runtime for executing queries by using a type system you define for your data." You need a type system to bypass the datamodel. Just pushing the issue around.

I think you should read the definition right from the website: https://graphql.org/learn/

I think GraphQL is just an way to bully the efforts of the W3C to standardize web technologies. It not just is non-standard, also is breaks any advantage of the HATEOAS principle.

Can you elaborate why SPARQL is the wrong tech?

From the website: "GraphQL is a query language for your API"

Maybe because it IS a query language? From the website: "GraphQL is a query language for your API"... just that it is _not_ a standardized API, so we won't take advantage of HATEOAS.

GraphQL also demands a certain data model. Just that it is not standardized. And no, RDF/XML is not the only representation for SPARQL. It can deal also with JSON.

Great. Another solution for an already-solved, already-standardized query API language (SPARQL).

We actually are on the semantic web for healthcare. See:

http://wiki.hl7.org/index.php?title=RDF_for_Semantic_Interop...

Other fields are moving towards semantic also

That's when having mongodb+RDBMS with the added complexity is really justified. On common cases, just drop mongodb and use the RDBMS for everything.