-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define input/output format #6
Comments
RDFPros:
Cons:
recommendation: The format MUST have a defined mapping to the RDF model, but there MAY be another serialization format |
GraphMLPros:
Cons:
|
Translator TSVSpec (loosely defined):
|
Translator JSONFollow KB standard Structurally almost identical to TSV above, the doc would have a section for nodes and a section for edges Cons:
|
I've expressed this reservation before (to you Chris), but I'm wondering whether simply defining the nodes and edges alone suffices for knowledge graph representation. In effect, we need to annotate statements, not just subject nodes of a statement, but simply annotating the predicates doesn't help either. It does seem to be necessary to treat statements as a reified node, then hang everything off of it: subject, predicate, object, evidence, provenance, etc. |
Chris, I wonder if we could also briefly mention GraphQL and Tinkerpop as well. The data model used in these languages/systems are also based on or similar to the property graph, so their pros and cons are also very similar to the ones of GraphML. I listed down additional pros and cons as follows.
|
@yy20716 we will need to be careful about how we map CURIEs to IRIs. If the exchange format is not an RDF serialization (which already has precisely defined mechanisms) we will need to embed a prefix mapping in the exchange file or have a standard one. |
I will write proposals as individual comments in this ticket
The text was updated successfully, but these errors were encountered: