We know that neo4j and Titan use property graph as their data model, which is more complicate and flexible than RDF. However, my team is building a graph database named gStore which is based on RDF datasets.
gStore can not support N-Quads or property graph because it can not deal with edges which have properties besides its label.
Below is a RDF dataset:
<John> <height> "170"
<John> <play> <football>
Below is a N-Quads dataset:
<John> <height> "170" "2017-02-01"
<John> <play> <football> "2016-03-04"
You can see that property graph is more general and can represent more relations in real life. However, RDF is more simple and our system is based on it. It is really hard to change the whole system's data model. Is there any way to transform a property graph into a RDF graph? If so, how to do it?
If the data model is well transformed, how can we query it? SPARQL language is used to query the RDF dataset, and neo4j has designed a Cypher language to query their property graph. But when we transform a property graph into a RDF graph, how can we query it?
RDF is a mechanism to serialize graph data. You can store your data in Neo4j as a property graph, query it using cypher, and serialize it automatically as RDF for data exchange and interoperability.
Check out the neosemantics plugin for Neo4j. It does exactly what you describe and more.
In the particular case you mention of properties in relationships, which RDF does not support, neosemantics will use RDF-star to avoid data loss during import/export.
Related
I am new to graph deep learning and I am trying to generate a graph from a matrix of node features by computing graph edges for all nodes within a given distance. I have found a concise way to do this with torch_geometric.nn.radius_graph() but I would like a similarly concise method of accomplishing the same task with tensorflow tensors.
My code is kind of a mess right now and I would like to change it significantly based on whatever method that is convenient for processing a graph dataset in this form. I am aware that I can write a class of connectivity utility functions but I don't think that is ideal.
I know that we can get schema information of tables using INFORMATION_SCHEMA.TABLES. Is there a similar method for BigQuery Models?
You can inspect everything related to the evaluation metrics by using ML.EVALUATE
https://cloud.google.com/bigquery-ml/docs/reference/standard-sql/bigqueryml-syntax-evaluate-overview
The ML.TRIAL_INFO function is used to display information regarding trials from a hyperparameter tuning model.
https://cloud.google.com/bigquery-ml/docs/reference/standard-sql/bigqueryml-syntax-trial-info
And there are many other functions to inspect a model using SQL, you can learn more about them here:
https://cloud.google.com/bigquery-ml/docs/reference#bigquery-ml-standard-sql-reference
BQML doesn't support information schema for Models yet.
Recently I have applied the OWL Micro reasoner to my Fuseki dataset but now when I query that dataset some queries timeout and others are really slow. However, I cannot change the reasoner once I need it for some of the queries. An approach I have seen are too create two datasets with the same data, one with inference with the OWL reasoner and the other with the raw data. Is that the best approach to follow or is there a better solution?
While serving TensorFlow models via TensorFlow-Serving, I need to expose custom meta data to the clients (e.g. a model's input data requirements, training information...).
I tried adding the information via tf.add_to_collection( <my_custom_key>, <value> ) before saving the model, and, sure enough, the information showed up in the .pb(txt) file used by the server.
However, currently it looks as if the response to querying metadata (e.g. via GET http://localhost:8501/v1/models/<my_model>/metadata) only returns the contents of the signature_def section (which also cannot be extended, the validator prevents that), and I know of no way to query contents of other sections.
Is there a way to serve/query custom meta data for TF Serving?
Unfortunately adding logic to allow serving metadata other than signaturedefs is not on the roadmap right now and I'm not sure we have a good understanding of the general use case for which supporting this would make sense.
Regarding how to serve the metadata stored in the saved model, presumably, you'd add a constant to your graph holding the tensor value of interest (the input/output shape), create a new signature using link below and do inference with that signature -- I've never seen this done but I can't imagine why it wouldn't work.
https://www.tensorflow.org/guide/saved_model#manually_build_a_savedmodel
While I still did not find a solution for TensorFlow Serving, it may be of interest to other readers that it can be achieved when using NVidia's Triton Inference Server.
While evaluating it as a TFS alternative (mainly for its built-in support for other model formats such as pytorch and ONNX), I found out that in Triton, it is possible to serve custom meta information via the Model Configuration Extension using the 'parameters' property. After adding
parameters: {
key: "inference_properties"
value: {
string_value: "<my-custom-inference-property-info>"
}
}
to the model's config.pbtxt file, I could retrieve the information on the client side. It's not extremely convenient, as one can only provide a flat map with string values, but still.
The benefit would be that I can store and load individual models using tf.train.export_meta_graph() but I'm not sure if this usage is what TensorFlow was designed for. Does it have any negative impacts on parallelism/performance, functionality, etc to use multiple graphs in parallel, as long as I don't want to share data between them?
It's not a good idea because passing data between models would require fetching from one session, and feeding the Python object back into the other session. Locally, that's unnecessary copy operations, and it's worse in the distributed setting.
There is now export_scoped_meta_graph() and import_scoped_meta_graph() in tf.contrib.framework.meta_graph to save and load parts of a graph and using a single global graph is recommended.