Explain "embedded triple" as a "quoted triple".

afs commented 3 years ago

It may help to explain <<:s :p :o>> as a quoted triple.

Embedded is motivated by the structural use of <<...>> terms as components of triples.

Quoted triple is motivated by being a reference to a triple without it being asserted.

This is in line with the use in "1.2 Overview" etc., and use in "2.1 Triples and occurrences".

gkellogg commented 3 years ago

My scan of the spec indicates that, for the most part, simply changing "embedded" to "quoted" throughout the document works pretty well. The grammar rule names are more complicated.

embTriple => quotedTriple – seems fair enough.
embSubject => quotedTripleSubject – a bit long winded, but better than quotedSubject IMO. We could consider something shorter such asquotedTripleS, orQTSubject`.
embObject => (same as for embSubject.
EmbTP => QuotedTP
EmbSubjectOrObject => QTSubjectOrObject
VarOrTermOrEmbTP => VarOrTermOrQuotedTP
ExprEmbTP => ExprQuotedTP

We probably need to rename test cases appropriately, and might consider renaming open issues that may not be closed by the end of the CG.

I suggest we create a branch off of this repo that we can collaborate on.

afs commented 3 years ago

find <root of tests> -type f ! -name manifest\* ! -name \*.html | xargs grep -i -l embedd => one file : sparql/eval/data-order-kind.ttl

Manifests:

All use of "embedded" is in mf:name except for the semantics suite. The semantics suite has some URIs with "embedded" in them and some text in rdfs:comment.

afs commented 3 years ago

At the telecon, there was a desire for more examples for quoted triples.

Here is some non-normative material in addition to #192 and the updates for the formal definitions in Section 2 and https://w3c.github.io/rdf-star/cg-spec/2021-07-01.html#dfn-embedded.

This may fit as a new section 2.1 and move the current section 2.1 "Triples and Occurences" to be 2.2.

Background

(not for the document - this is the relevant terminology from RDF 1.1.)

An RDF triple is a tuple of three components: subject, predicate and object.
Section 3.1 of RDF 1.1 Concepts and Abstract Syntax.

These components, IRIs, literals and blank nodes, are collectively known as RDF terms.
RDF 1.1 Concepts and Abstract Syntax and in SPARQL.

An RDF graph is a set of triples.
RDF Concepts, section "3. RDF Graphs".

Asserted Triples

An asserted triple is a element of the set of triples. RDF Concepts, section "1.2 Resources and Statements".

Quoted Triples

The RDF-star report introduces quoted triple, which a new kind of RDF term. A quoted triple is a triple used as the subject or object of another triple. Quoted triples can also be called "embedded triples".

A quoted triple is written in Turtle-star and N-Triples-star using delimiters << and >>.

The definition of quoted triple is recursive. A quoted triple can itself have a subject or object component which is another quoted triple. Cycles are not allowed and can not be written in any RDF syntax.

RDF Term examples

<< :a :name "Alice" >>

is a quoted triple in Turtle-star syntax.

<< << :a :name "Alice" >> :reportedBy :charlie >>

is a quoted triple with property :reportedBy and whose subject is another quoted triple :a :name "Alice".

Quoted triples can appear in the object position:

:deduction741 :basedOn << :observation259 :value 8.5e4 >> .

RDF Graph examples

In the graph

:bob :name "Bob" .
<< :a :name "Alice" >> :statedBy :bob .

there is a quoted triple :a :name "Alice" which is used as subject for an asserted triple.

The example graph has two asserted triples:

:bob :name "Bob" .
<< :a :name "Alice" >> :statedBy :bob .

The graph does not have an asserted triple :a :name "Alice" because the triple :a :name "Alice" is not an element of the set of triples.

A triple can be used as both an asserted triple and quoted triple in the same graph.

:bob :name "Bob" .
:a :name "Alice" .
<< :a :name "Alice" >> :statedBy :bob .

Annotation Syntax

Annotation syntax provides a convenience short cut using delimiters {| and |}. It is used to assert a triple and also use the triple as a quoted triple.

Annotation syntax does not appear in the RDF-star abstract data model. It is only a syntactic short cut and the RDF-star abstract data model does not distinguished how the triples were written.

:a :name "Alice" {| :statedBy :bob ; :recorded "2021-07-07"^^xsd:date |} .

is the same set of triples as:

<< :a :name "Alice" >> :statedBy :bob .
<< :a :name "Alice" >> :recorded "2021-07-07"^^xsd:date .
:a :name "Alice"

and it contains three asserted triples.

gkellogg commented 3 years ago

A quoted triple is written in Turtle-star and N-Triples-star using delimiters << and >>.

Maybe "Turtle-star and related syntaxes", since it also includes N-Quads-star and TriG-star.

TallTed commented 3 years ago

Annotation syntax does not appear in the RDF-star abstract data model. It is only a syntactic short cut and the RDF-star abstract data model does not distinguished how the triples were written.

Minor typos -- add a comma, remove an ed --

Annotation syntax does not appear in the RDF-star abstract data model. It is only a syntactic short cut, and the RDF-star abstract data model does not distinguish how the triples were written.

(Why not a PR where such nits are easier to flag and address?)

afs commented 3 years ago

@TallTed - This is focusing on the content. Are we agreed on the content and intent here?

There is a separate PR in progress for other changes related to quoted triples. Two separate PRs in progress around the same area is not good.

TallTed commented 3 years ago

@afs --

Issue text is a terrible place to crowd-source/massage/collaborate on content. Github collaboration features include a wiki space (which would need to be activated for this repo), and draft PRs (which are not horribly difficult to rebase), among other tools.

That said --

Overall, this content looks good to me. Modulo the missing comma and incorrect verb tense I flagged above. I would suggest actually keeping the background/introduction within this insertion, as I think summarizes (only!) the relevant terms from elsewhere more concisely and contiguously than the other sources I know of for the same few statements.

Also worth considering -- I have found that body text preceding inset examples (making the examples objects) leads to better comprehension than having that body text follow the example (making the examples subjects). (Also, rather than colons or no punctuation, emdashes should be used between incomplete sentences of body text that bracket such example blocks. This would be easy to offer as a PR suggestion or wiki edit; it's all but impossible to provide usefully here.)

gkellogg commented 3 years ago

The text needs to be added to PR #192; if @afs doesn't get to it, I'll take a stab at it. Typically, ReSpec formatting dictates some minor changes, but I take @TallTed's points.

pchampin commented 3 years ago

@gkellogg where do you want to insert the text of the issue? For me, the text was meant to reach consensus on what should be in this PR. But it summarizes things that are already contained (or referenced) in the spec already.

afs commented 3 years ago

I take @TallTed's point about intro. For the examples, too much text before also has disadvantages - need to find a balance. Now we have the target examples, that's easier.

The text needs some work still to fit in (e.g I've realised we are 75% defining "asserted" - while it appears in RDF-concepts, as referenced, it isn't really definitional and we're relying on it so worth investigating promoting it).

I'll add to PR #192. @gkellogg - it looks complete now - is that right?

Timing - we have a telecon 16/July. I'll add to #192 in the next few days.

We are moving quite fast here - there may be valid concerns about the change we haven't thought of. A goal for next telecon is, to my mind, to have a preview version for a wider audience, including outside the telecon community. Whether that's the main editors draft or not can be decided at the telecon. If it does not overlap with vocabulary work, it will be reversible by git.

gkellogg commented 3 years ago

I take @TallTed's point about intro. For the examples, too much text before also has disadvantages - need to find a balance. Now we have the target examples, that's easier.

The text needs some work still to fit in (e.g I've realised we are 75% defining "asserted" - while it appears in RDF-concepts, as referenced, it isn't really definitional and we're relying on it so worth investigating promoting it).

I'll add to PR #192. @gkellogg - it looks complete now - is that right?

yes, ready otherwise. we can change to “ready for review after”.

Timing - we have a telecon 16/July. I'll add to #192 in the next few days.

We are moving quite fast here - there may be valid concerns about the change we haven't thought of. A goal for next telecon is, to my mind, to have a preview version for a wider audience, including outside the telecon community. Whether that's the main editors draft or not can be decided at the telecon. If it does not overlap with vocabulary work, it will be reversible by git.

I think the finalized PR is the best place to reach consensus. But, the editor’s draft, sort of by definition, does not necessarily represent a group CI census, just the editor’s best efforts at expressing their understanding of group direction.

w3c / rdf-star