- From: Pierre-Antoine Champin <pierre-antoine@w3.org>
- Date: Mon, 27 Jan 2025 12:29:42 +0100
- To: Souripriya Das <souripriya.das@oracle.com>, Andy Seaborne <andy@apache.org>, "public-rdf-star-wg@w3.org" <public-rdf-star-wg@w3.org>
- Message-ID: <6e6c7570-2046-4517-a0bb-e42594c9c36d@w3.org>
On 27/01/2025 11:36, Souripriya Das wrote: > Andy wrote: > >> That's the N-Triples that I'm getting for that Turtle example. > It does not have a nested triple term. > > That's good but just to be sure, let me tweak the Turtle 1.2 statement > a bit to avoid the use of explicit reifiers. > > Would the following statement in Turtle 1.2: > :s :believes << :s2 :believes << :s3 :p3 :o3 >> >> . > be a valid statement in N-Triples 1.2 as well? No, because the '<< ... >>' construct (reification) is only part of Turtle, not of N-Triples. Not ot be confused with the '<<( ... )>>' construct (triple terms), which is also part of N-Triples. And yes, recursive triple terms are possible, e.g. _:b1 rdf:reifies <<( _:b2 rdf:reifies <<( <tag:s> <tag:p> <tag:o> )>> )>> . This is valid N-Triples, and contains 1 (asserted) triple. best > > Or, would it always require use of multiple statements in N-Triples, > something like the following? > :s believes _:b2 . > _:b2 rdf:reifies <<( :s2 :believes _:b3 )>> . > _:b3 rdf:reifies <<( :s3 :p3 :o3 )>> . > Thanks, > Souri. > > ------------------------------------------------------------------------ > *From:* Andy Seaborne <andy@apache.org> > *Sent:* Saturday, January 25, 2025 7:09 AM > *To:* public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org> > *Subject:* Re: [External] : Can a triple-term in an N-Triple 1.2 > statement have "infinite" number of atomic terms? > > > > On 24/01/2025 17:31, Souripriya Das wrote: >> In N-Triple 1.1 syntax, a statement consists of exactly three >> (atomic) terms and I am hoping that N-Triple 1.2 will be a simple >> extension that will allow 5-term statements as well, subject to the >> restriction that the predicate for such 5-term statements will always >> be rdf:reifies. >> >> Thus, the following statement in Turtle 1.2: >> :s :believes << :s2 :believes << :s3 :p3 :o3 ~ :r3 >> ~ :r2 >> . >> will be written in N-Triple 1.2 as follows: >> :s believes :r2 . >> :r2 rdf:reifies <<( :s2 :believes :r3 )>> . >> :r3 rdf:reifies <<( :s3 :p3 :o3 )>> . >> >> Is this aligned with the current thinking in the WG? > > That's the N-Triples that I'm getting for that Turtle example. > It does not have a nested triple term. > >> >> Thanks, >> Souri. >> ------------------------------------------------------------------------ >> *From:* Souripriya Das <souripriya.das@oracle.com> >> <mailto:souripriya.das@oracle.com> >> *Sent:* Thursday, January 23, 2025 11:59 AM >> *To:* RDF-star WG <public-rdf-star-wg@w3.org> >> <mailto:public-rdf-star-wg@w3.org> >> *Subject:* [External] : Can a triple-term in an N-Triple 1.2 >> statement have "infinite" number of atomic terms? >> Would the following be a valid N-Triple 1.2 statement, where n can >> be, say, 1000? >> (There will be a total of 2*1000 + 1 = 2001 "atomic" terms in the >> triple-term used as the object.) >> >> :s :p <<( :s1 :p1 <<( :s2 :p2 <<( ... <<( :sn :pn :on )>> )>> >> )>> )>> . > > The RDF Abstract Syntax allows it and N-triples has concrete syntax > for it. > https://www.w3.org/TR/rdf12-concepts/#section-triples > <https://urldefense.com/v3/__https://www.w3.org/TR/rdf12-concepts/*section-triples__;Iw!!ACWV5N9M2RV99hQ!JYEvlde5NuL_h5csMvH6AwkIwDQ-0an7pS64QPbyPujF1z1Hq5zPtm0_FQrFPc5jqgNd1kTb5R4zo_5x$> > https://www.w3.org/TR/rdf12-concepts/#section-triple-terms > <https://urldefense.com/v3/__https://www.w3.org/TR/rdf12-concepts/*section-triple-terms__;Iw!!ACWV5N9M2RV99hQ!JYEvlde5NuL_h5csMvH6AwkIwDQ-0an7pS64QPbyPujF1z1Hq5zPtm0_FQrFPc5jqgNd1kTb5XDNa7h2$> > (2nd point) > > Personally, I think nesting in triple terms will not be common, and > many levels very, very uncommon. > But the ability to create triple terms for any triple data does lead > to providing for nesting. > > Andy > > >> >> Thanks, >> Souri. >> >
Received on Monday, 27 January 2025 11:29:46 UTC