> The reason why P141 has not as range "Property" is simply because this > was not supported by any reasonable implementation
I've heard this objection many times. But it holds equally for the host of Pn.1 properties: they have domain "Property" (usually P2_has_type). > isomorphism of E13,P140, P2, P141 with the RDF Reification > vocabulary: rdf:Statement, rdf:subject, rdf:property, rdf:object. This trick with P2 is cute! But: - it concerns RDF implementation; I think the CRM implementation-independent standard should also say something on the matter -- we're talking here a specific set of values, namely the CRM properties - since P2 is so useful, it should not be used on its own for this purpose, but subpropertied. E.g. in RS we use it to express status, reply disposition, disposition towards an old or new value (object)... > In the meanwhile, I regard Named Graphs as superior to reification, much > cleaner. In addition, Named Graphs can preserve the complete unit of > statements made together, and that must be understood as one complex > statement In RS we ended up using the OAC annotation ontology (also sponsored by Mellon). We use rdf:Statement to capture the annotation target, I attach a picture. - Named graphs often have slower performance in semantic repositories, since there are no primary indexes for them (e.g. there are SPOG and OPSG indexes, but not GSPO) - Many people are wary of using MANY named graphs (potentially one per statement), though such experiments are starting to appear - There's no problem to attach a "graph" to rdf:Statement (e.g. dcterms:isPartOf as in the picture) - For me the decisive factor was flexibility: I can use or skip rdf:object, thus talk about a specific role only, or also about the object in that role
