Closed dwinston closed 2 years ago
I find you very brave for trying to model a solution, because when I wondered about reification I went straight on googling "how does rdf do that?". And indeed there's a workaround in rdf, the _rdf:Statement (which I haven't encountered in application yet, but would very much like to). :myStatement a rdf:Statement ; rdf:subject :customer-1 ; rdf:predicate :knows ; rdf:object :customer-2 ; :since "2014"^^xsd:gYear ._ This seems to express well what we want to say in this case. But I don't have experience in transformations to rdf, so I don't know what effect such verbosity could have?
Another way could be with a named graph perhaps. We can have the graph :oneKnowsTwo, which may contain the triples :customer-1 :knows :customer-2 ; :since "2014"^^xsd:gYear . It's not exactly the same though, because we don't associate since to the entire triple above, but to customer-1 only. Plus, I'm not sure all triple stores provide this capability.
And I know nothing about RDF*...
Reification in RDF (i.e., the use of rdf:Statement
) is originally intended to be a way to "make statements about statements". Since RDF statements ("triples") are really edges in the graph, you can think of reification as letting you add "edge properties" (in LPG parlance). Reification is not always the best way to do things. Sometimes it is best to simply apply the rule "most problems in computer science can be solved by adding one level of indirection". ;-) What I mean by this is that rather than having a direct link from X to Y, you add an intervening node (X to I, I to Y) and then add suitable properties to the new node. Alternatively, you link I to X and Y with suitably named properties. We can discuss during the next session.
Discussed right at the beginning of session 3
In Section 2.2.4 (emphasis mine):
In Figure 2.3, only the second approach, reification, is illustrated. What does (an illustration of) the first approach, changing how one models relationships, look like?
Does it look like modeling a Relationship as an RDF Class (a Concept in your abstraction) with the restriction that the Class has (at least) two Object Properties that represent roles of entities in the relationship? In other words, in terms of the book's graph abstraction, a Relationship is a kind of Concept, and thus every Relationship Attribute is a kind of Concept Attribute?
My illustration of this modeling, in the style of Figure 2.3, is below (perhaps if the relationship is directional / not symmetric, the "agent" object properties / concept attributes below could be e.g. "knower" and "knowee"?):