How can I generate a turtle file containing Quoted Triples using rdflib?

[joylix]

See example 19 of w3 rdf1.2 specification,
I want to use rdflib to generate an rdf turtle file with the following content:

PREFIX :  <http://www.example.org/>
<< :s :p :o >> :p2 :o2 .

I didn't find any reference to this in the documentation or examples. How should I write the corresponding python code? I'm just starting to learn and use rdflib, thanks for your help！

[niklasl]

Hi! RDF 1.2 is still a Working Draft, and the exact interpretation of quoted triples (now called triple terms) is yet to be finalized. Thus it would be premature for RDFLib to support it at this stage. Experimental third party tools could do so, if they responsibly warn that this is not a standard and still subject to revisions.

Rest assured that once we're getting closer to a definitive state this will be properly implemented to ensure future interoperability. Meanwhile, it would be great to know about your specific use case is (even if it is experimental), so that we can assess the applicability of the proposed semantics with such usage requirements.

[joylix]

I really need to use rdflib to read and write rdf * turtle files because it is very useful when operating graph databases. Please take a look at the example of neo4j data:
(:Bob) - [:met {'at': 'London ', 'date': '2008-08-08'}] ->( :Mary).
I need to read and convert it into:

 PREFIX :    <http://www.example.org/>
<< :Bob :met :Mary>> :at :London.

And save it in an RDF file, so that it can be imported into other neo4j databases when needed.
There are now many rdf visualization tools that support rdf star syntax, such as:
issemantic.net
But currently, I haven't found a good way to write a rdf file containing quoted triples, especially for storing properties of Neo4's edge (relationship) .
Similarly, as EXAMPLE 20 about Annotated Triple:
:john :hit :mike {| :saidBy :bob |} .
So this feature is really important and urgently needed.

[niklasl]

Yes, interop with graph databases, with added semantics to reflect implied meaning and work with the RDF conceptual model and semantics (to cater for data integration and reasoning), is paramount for the RDF-star WG (of which I'm a member; though here I speak for my own position).

There is active discussion about the implied meaning of various cases. Some pertain to minute, opqaue data provenance; some, such as I interpret your examples, referring to qualifications of the interpretation of the "quoted" triples.

(Though it is not obvious, since this could either be the event of Bob and Mary meeing in London, as I take it, or the recording of such an RDF triple in a data row happening somehow to reside in or pertain to London (a less intuitive interpretation IMHO, with nothing else to go on; but a valid, different use case). It is simply determined by expected meaning (particularly the domain) of :at, which I here assume is simply a qualified event when these to persons met. (There may be many of those, and recordings of such facts, etc.))

A rough approximation in RDF 1.1 (which RDFLib supports) is possible today using reification:

<Bob> :met <Mary> .

[] rdf:subject <Bob> ;
    rdf:predicate :met ;
    rdf:object <Mary> ;
    :at <London> ;
    :date '2008-08-08' .

But be cautious that the exact meaning of that may be different from what RDF 1.2 defines.

(Particularly, although it has been suggested that RDF-star should just be sugar for reification; it is oft criticized as being too little of an improvement to actually handle the various collected use cases and requirements. Particularly, compare my assumption of this qualification being an event, with the reification notion of a "concrete realization of a triple, such as a document in a surface syntax" . Are we conflating notions here? Is the same event also qualifyng the fact of <Mary> :met <Bob>? Conflations of some kind are inevitable when we define abstract entities, but should generally be avoided when possible. While this all may come across as overly philosophical nitpicking, it actually has far-reaching consequences for interoperability and data integration. We want to get this right, so that users do not have to think too deeply about it, accidentally getting the wrong consequences when their knowledge graphs grow and conceptual models evolve!)

[joylix]

Let's have a look at another example of neo4j:

 (:model_x) - [:hasPart {quantity:3, connection:'weld'}] -> (:part_1)
(:model_z) - [:hasPart {quantity:4, connection:'screw-connected'}] -> (:part_1)

The corresponding RDF data is as follows:

<<:model_x :hasPart :part_1>> :quantity 3;  
                          :connection :weld .
<<:model_z :hasPart :part_1>> :quantity 4;  
                          :connection :screw-connected .

Both quantity and connection should be used as properties of "hasPart"(not part_1), because the part_1 of other models may be Screw-connected, and it's quantity is not necessarily 4. So, I need to use rdflib to generate the above rdf data exactly, not with blank nodes or some other means. Of course, there are many more other application examples.
In short, similar data applications will become more and more widespread.

[niklasl]

Thank you for this additional example! It highlights more of the challenge in explaining and getting this right.

First off: yes! What will go into RDF 1.2 for this should not just qualify the subject (the model) or object (the wheel), but specific relationships (expressed using triples). But note that is not yet finalized what that syntax will mean in RDF 1.2, so it is undefined what that RDF data is. (I am of course assuming you mean properties of the statement using that :hasPart property (as a predicate), not the property itself; as we don't want to redefine the meaning of it for any other triples.)

I do wonder if you assume here that the :model_z :hasPart :wheel triple itself is also asserted in the graph? For that, you should probably use the annotation syntax:

:model_z :hasPart :wheel {| :quantity 4 ; :isPurchasedParts "True" |} .

(Which is a shorthand for what you wrote and an assertion of the simple triple.)

Note that there is a conceptual difference between an edge in Neo4J and a triple in RDF. The former says "Relationships must have a type (one type) to define (classify) what type of relationship they are". In that model, there can be multiple edges with the same relationship type. So to properly express that in RDF, we need to have some kind of occurrence of the triple (nameable with an IRI, or as a blank node). But we don't want to burden the data user with too much of that (when creating or querying).

The abstract triple itself means only what the definition of :hasPart defines as a relationship (a "relationship type" in Neo4J terminology) -- we cannot alter that meaning. (There is more information in a qualification, and omitting that entity leads to what in RDF-star was called "the seminal error".) The most direct representation is to use what is known as the "singleton property pattern", but that has some drawbacks: most crucially that it does not represent the simple triple, and also some common implementation problems (pertaining to efficient indexing).

That is why we are working out how to best represent these occurrences of triples; likely by adding triple terms (as atomic structures) for which occurrences are defined (being whatever you need them to be, in an integratable manner).

In your example, the simple partitive relationship between the model and a wheel component used in the model appears to be qualified as a part specification, with a quantity and purchasable status. It thus does not simply have that wheel part; there is a specificity to it. A fifth wheel could be used as a spare part in the trunk, for instance. That could be another partitive qualification, if you model it like that, or you might want to keep that detail out of this simple quantity specification, and keep just the one qualification you have (bumping up the quantity, and leaving out such further placement details).

This feature should be flexible and safe enough to cater for various such needs, without making data merging accidentally conflate things (but also support intentional merging of, for instance, data about meeting events, or identical part specifications).

[joylix]

I edited the example a bit before seeing your reply so that it more accurately conveys what I mean.
Thank you for your in-depth explanation of the issue.
really， in the previous example, hasPart is just a general term for a type of relationship, It also has some subclasses, such as: hasKeyParts, hasImportantParts .
For model_z, this statement is just an instance of an edge (in neo4j)， so,
{| :quantity 4 ; :isPurchasedParts "True" |} is only for this specific edge, not for the predicate of "hasPart".
I am not able to understand the semantic differences of these RDF syntaxes in more depth now. I just want to find a convenient way to exchange data between graph data (such as neo4j) and RDF files. Of course, you experts will provide more comprehensive and powerful solutions. Looking forward to it. Thank you!