bad examples in RDF* document

[pfps]

The current RDF* document has many examples that have the same problem that the seminal example has.

Examples 1 through 7 involve provenance. Although they only use one property, they will have the same problem that the seminal example has as soon as there is a more involved notion of provenance. Example 8 shows what is needed to fix provenance. Examples 9 and 10 are almost exactly the seminal example and have the same problem it does.

Quite a few later examples have similar problems when extended.

RDF* deserves examples that do not need indirection. If there are none, then there is something wrong with RDF*.

[TallTed]

Please note, "RDF*" is an old thing, which we are not working on any longer. Our ongoing work is on "RDF-star". Yes, these names are pronounced the same. When referencing them in writing, however, they must be spelled correctly, to communicate clearly.

"The current RDF* document" is ambiguous, as it could refer to the latest document which discussed "RDF*", or it could refer to the latest editor's draft of RDF-star, or it could refer to the latest date-stamped snapshot draft of RDF-star, or any of many other things. Please link to something we can click to, so we can all (you included) be sure we're discussing the same thing.

[pchampin]

Although they only use one property, they will have the same problem that the seminal example has as soon as there is a more involved notion of provenance

yes, if you make them more complex; but if you keep them simple, I would argue that there is no absolute need to use indirection. The recent blog post I wrote with the help of other members of the group develops this idea.

RDF* deserves examples that do not need indirection. If there are none, then there is something wrong with RDF*.

Even if we do "fix" the first examples, and end up with only examples with indirection, I would disagree that "there is something wrong with [RDF-star]". RDF-star allows to represent (and differentiate) different kinds of indirections (mention of a triple, mention of a situation, occurrence of a situation...) which long discussions (e.g. here or there) didn't manage to exhaust... That's an added in value in itsef, IMO.

[pfps]

The problem with simple (simplistic) solutions is that they very often are not compatible with more complex (realistic) solutions. If the document is supposed to be used then it should not push for solutions that cause problems.

If all realistic solutions that use RDF-star require auxiliary constructs (even just extra triples of a certain kind) then it would be much better if RDF-sart was based around notions that include these auxiliary constructs. A half-solution to a problem is generally worse than no solution.

[pchampin]

The problem with simple (simplistic) solutions is that they very often are not compatible with more complex (realistic) solutions. If the document is supposed to be used then it should not push for solutions that cause problems.

As I explained in my answer to Antoine on the mailing list, I am not convinced that there is a crisp line between simplistic and realistic solutions. It depends on your use-case. Someone's realistic (enough) model is simplistic for someone else's needs...

If all realistic solutions that use RDF-star require auxiliary constructs (even just extra triples of a certain kind) then it would be much better if RDF-sart was based around notions that include these auxiliary constructs.

I don't quite understand what you mean by "based around notions that include".
The very point of of allowing triples to be subject or object of other triples is to enable these auxiliary constructs. What else do you think is required?

[pfps]

If any reasonable use of RDF-star requires a stand-off from the embedded triple, as in

<<x y z>> rdf-star:occurence  [:a :b; :d :c]

then it would at least be nice to have a compact syntax for this or, even better, base RDF-star around this.

If a better syntax is desired I suggest:

[rdf:subject x; rdf:predicate y; rdf:object z] :a :b; :d :c

[TallTed]

@pfps -- Would you please edit that comment again, to add codefences (single ` or triple ``` backticks) around the pseudo-RDF-star syntax, and to correct the instances of start and sart to star, or whatever it was you really intended?

"Obvious" typos have added months of unproductive discussion in some groups in which I've participated previously, because of conflicting "obvious" reads of intent, and I fear the same may otherwise occur here.

[pfps]

@TallTed I find RDF-star very difficult to type correctly. RDF* is very much easier.

[TallTed]

@pfps -- Unfortunately, RDF* has a great many other negatives Vs. RDF-star, not least being that it may be pronounced "RDF-wildcard". You might try drafting your posts with RDF* and doing a quick search-and-replace before posting, if you can figure out all the appropriate escaping for your editor.

[pchampin]

If any reasonable use of RDF-star requires a stand-off from the embedded triple, as in

<<x y z>> rdf-star:occurence  [:a :b; :d :c]

then it would at least be nice to have a compact syntax for this or, even better, base RDF-star around this.

It would indeed be nice, if a single indirection could fit all possible use cases, which (as I stated above) I don't think is the case.

If a better syntax is desired I suggest:

[rdf:subject x; rdf:predicate y; rdf:object z] :a :b; :d :c

And and of course you can still do this in RDF-star if that fits your use-case better than quoted triples.