Closed pchampin closed 3 years ago
@pfps you might want to look at this PR, see if I captured your ideas correctly. That is, apart from the "hidden IRIs" part which I know you are no a big fan of... About that, I included some text in the "remarks" to (hopefully) better explain the rationale.
This PR appears to be similar to the semantics I stated. The use of unnamed predicates is a significant difference. My proposed used the standard RDF reification vocabulary and added particular predicate IRIs for a purpose - users can intermix RDF* syntax with RDF reification syntax.
Section 6.1: Would it be possible to suggest ST, PT, OT, SS, PS, and OS IRIs as per @pfps email? even if it is not normative? I'm also concerned about 6.3.2. It reads like RDF-star graphs (in general) are not interoperable (modulo mapping between the different ST, PT, OT, etc). Would that affect adoption? that's another question. We might also consider having this section in the document coming before SPARQL, Turtle.
I find Sec.6.3.2 quite clear and convincing. Perhaps the beginning of of the second paragraph may be phrased in a more positive way.
So, my question in this context is actually the opposite: why should we introduce actual IRIs for ST, PT, OT, SS, PS, and OS? What would be the benefit?
A question regarding the property described in Sec.6.3.1: This property seems undesirable to me because it may cause unexpected behavior. Can some explain why this would not be a problem in practice?
It appears to me that 6.3.1 does not correctly describe the issue. The issue is not merging RDF graphs, but merging RDF graphs. If implementations work with only with RDF graphs then the issue should not arise.
@pfps I am not sure whether you get notified for change suggestions, so just in case: https://github.com/w3c/rdf-star/pull/88/files#r575393794 Would this fix address your comment above?
source: https://lists.w3.org/Archives/Public/public-rdf-star/2021Jan/0059.html
Preview | Diff