I say the best way is to create a new vocabulary. Here is a sketch. I use prefixes to make clear what I mean:

• Def: A pg:Entity is a rdf:IRI (but not vice versa); its type is an pg:EntityType
• Def: A pg:RelationType is a subclass of rdf:Property with domain and rage pg:EntityType
• Def A pg:Relation is a rdf:Statement with subject and object a pg:Entity and predicate a pg:RelationType
• Def: A pg:PropertyType is a subclass of rdf:Property with domain pg:Entity
• Def: A pg:Property is a pair (pg:PropertyType, value). A rdf:Statment is interpreted as pg:Property if the predicate is a pg:PropertyType or the object is a rdf:Literal or Blank Node (indicating a complex property value)
• pg:Properties can be assigned to reifed rdf:Statments

Example:

ex:Alice a ex:Person ;
   ex:name "Alice";
ex:likes ex:Bob ;
ex:employedAs ex:Scientist .

ex:Bob a ex:Person .

# new Property-Graph Ontology

ex:Alice a pg:Entity .
#OR
ex:Person a pg:EntityType . 


ex:name a pg:PropertyType . # can be inferred
ex:likes a pg:RelationType.  #  can be inferred ?
ex:employedAs a pg:PropertyType # this cannot be inferred and must be asserted!

 

Named graphs as property value? I didn't think about it, but this is a very interesting idea. Why not?

The link you provided is good example for what I mean: you must specify a mapping. If the PG side is the active consumer, the problem is not only a technical, because you know how to map. But there is general solution without any additional information.

Can you use named graphs as "sub-graphs"?

And have you looked at other RDF -> PG mapping approaches? For example: https://github.com/Rothamsted/rdf2pg#mapping-rdf-to-cypherneo4j-entities-general-concepts

Thank you all for reading me note and making this excellent remaks!

@HughGlaser Your summarised my thoughts very nicely. Maybe the term "expressivness" is misleading. It did not mean that either graph style is more powerful. As you said they both can model the world but they do it differently.

I will try to respond to your objections. They all come down to the questions: is the property/relation question is a real deep issue or is it a superflous pettifoggery of a shallow difference? If there are differences, can they be listed (are the sufficient arguments for beeig a property or relation?)

The answer may be a bit surprising. I used the term "graph style" for a reason. There is the concept of Thought Style. It is an important concept in the field of history of sciences, it is the basis of the concept Paradigm. To simplify it: you have a style of thinking that is shaped by your context.

I make a hypothesis: there are two thought styles here, the context of RDF/Linked Data and the context of Property Graph/Applied Mathematics. A member of the first groups says: "What are you talking about? There is no difference!" A member of the other group might say: "Why don't you see it?"

I do not want to convince you to adopt anything, but I do want you to accept that the difference property/relation is made by others. You cannot deny that ER or (UML) class models exist and they distinguish between membership and association. I think that accepting this fact is the necessary condition for bridging PG and RDF. This is the topic of this thread, is it not ? If you 'simply decide not to use the property stuff of the PG' (to cite @HughGlaser) than you are not supporting PG! I also think that RDF must do something here because it provides the more general/abstract graph style.

So, I rephrase the question of @HughGlaser and @dbooth-boston:

IF you accept the difference between relation/property THEN how do you distinguish them?

Well, this is a very good question and the discussion can be extremly deep if not confusing (for example: intrinsic versus extrinsic properties). This is not the right place for such a discussion. Putting all philosophical questions aside I think finally it is choice that made by the guys who create the model. (Whether or not it is a bad thing to have this choice is again another question!)

I would list following general rules:

• We must distinguish three things: properties/relations and those things which are related and own properties. The best name of these things is in my opinion entity (like in the ER model). An entity is a thing we talk about, it is the object of the model. A necessary condition is that an entity has an identity (otherwise it could not a be thing we talk about). But this is not sufficient because there are things that have an identity but can be regarded as property (value), like an email address. It follows that 'entity' is a stronger term than RDF's 'resource'.

• A relation is a relation in the mathematical sense between entities (an n-ary logical predicate r(x,y,z...), where x,y,z... are entities). Putting higher relations aside (this is again again another question) a 'relation' is a binary ordered (directed) relation of two entities.

• A property does not have an existence or identity by its own, it is always owned by an entity. If the entity is destroyed, all owend properties are also destroyed. A property can have any complex value, it is not restricted to be a single string literal. It can be an URI, a structure or sub-graph.

• A property cannot be related to something, only its owning entity.

@namedgraph : I am sorry, but RDF is not what you are showing. RDF is a labeled directed graph plus three nodes types: IRI, Blank and Literal. There is a restriction that limits Literals to be leave nodes. This additional feature changes the graph completly. If you define a owl:DatatypeProperty it says that the object-node of an RDF statement shall be a Literal (please correct me if I am wrong here). I believe, we agree that Literals are properties in the PG sense (I said this several times). But what about IRIs and Blanks? Can they be interpreted as properties in the PG sense? Can a whole sub-graph be a property value in the PG sense? So owl:DatatypeProperty and owl:ObjectProperty do not help here.