Your explanation is very clear. Thanks. I appreciate your taking the time to break it all down according to what I did or did not understand. That helps a great deal.
Also, while your example of "Message MM78910 says (#asserts) that Shipment XX1234 is in New York" is very clear, I have a follow-up question. Are Assertions nothing more than short-cut "joins" through multiple degrees of separation in a graph?
In other words… I may be wrong but I believe your example could be completely modeled in a graph with no notion of an Assertion, at all. For example…
- Relationship 1 :: S = "Message MM78910", P = "Describes" (or "Contains"), O = "Shipment XX1234"
- Relationship 2 :: S = "Shipment XX1234", P ="is in", O = "New York"
In the above example, wouldn't the Assertion be implied, confirmed, and just as valid through a join of the two Relationships through the vertex node "Shipment XX1234"… or, am I missing something? If my interpretation is accurate, then isn't an Assertion just a short-cut or short-hand notation for joining across a more granular or decomposed graph structure?
Frank Guerino, Chairman
The International Foundation for Information Technology (IF4IT)
Our particular application involved validating the contents of messages received from suppliers. So what we need to capture is not just “Shipment XX1234 is
in New York”, but rather “Message MM78910 says that Shipment XX1234 is in New York”. And we have to compare that with other knowledge we have, and other reports we may have from other sources. If there is no conflict in all that information, we can accept
the statement as true, but when there is a conflict, some remedial action must be taken, lest the operations information base become inconsistent. The particular USE of the named graph for “Shipment XX1234 is in New York” is as an operand of the RDF verb/predicate
...#asserts (which is just a clarification of ‘says’). So that particular use/role of the Named Graph is an “assertion”. That is, it is the intent of the message that the named graph be accepted as a fact.
You are right when you say that a named graph could be considered a ‘topic’ – a sentence that plays a role in verbs relating to conversation, of which assertion
is a special case. In a related way, a named graph may be used as an operand of RDF verbs/predicates that express “modalities”: S is possible/impossible; S is required; S is desirable/undesirable; S is prohibited.
Others have discussed the use of the Named Graph as an operand of ...#causes, in which there are two roles for named graphs, loosely called “cause” and “effect”.
In that usage both named graphs might be taken as facts a priori, and the intent of the use is to relate them “causally”. There are many other uses of named graphs for other purposes. From a natural language point of view, I would say that a named graph
is used whenever a sentence is the subject or object of the verb in another sentence. In formal logic, a named graph is a particular representation of a ‘nominalized proposition’, literally a “proposition converted to a noun” (because ‘nouns’ and pro-nouns
are the speech elements that play roles in verbs and thus in sentences, or equivalently, in other ‘propositions’).
BTW, you are also correct about named graphs being used as buckets of triples. Used in that way, a named graph is a “knowledge management object” – a “set
of knowledge” (only maybe a “theory”) that is manipulated as a body. And in particular, that is a way in which metadata can be attached to parts of a knowledge base. For example, this set of triples together represents a state of the world at a given time.