AW: AW: Next weeks discussions and decision-making for RDF Star WG

Thank you for the explanation, Peter. I personally favor option 2, but will also gather additional feedback internally and bring that to the call.

Best,

Felix

Von: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Datum: Sonntag, 12. November 2023 um 13:27
An: public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
Betreff: Re: AW: Next weeks discussions and decision-making for RDF Star WG
As far as I can tell, although it is well disguised, option 2 is the way the
working group was progressing.  This option would probably be very close or
identical to existing RDF-star implementations.

In my opinion for the working group to take up any other option requires
either finishing option 2 or making a determination that quoted triples as in
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2023%2FWD-rdf12-concepts-20231013%2F%23section-triples&data=05%7C01%7Cfelix.sasaki%40sap.com%7Cf16cfd102268469fd0c808dbe37ab856%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638353888443816792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pkZGVcyQPIScQ3U898NQJ%2FVtNo164HYCHMgePg5ys5Y%3D&reserved=0<https://www.w3.org/TR/2023/WD-rdf12-concepts-20231013/#section-triples> are
fundamentally flawed.

peter


On 11/12/23 03:41, Sasaki, Felix wrote:
> Hi Adrian, Gregg and all,
>
> Adrian, thanks a lot for the summary. As somebody relatively new to the
> working group and not attending the last meeting, I am struggling to
> understand the impact of the options.
>
> How is this topic related to RDF star? How would it influence the role of
> existing RDF star implementations
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Frdf-star%2Fimplementations.html&data=05%7C01%7Cfelix.sasaki%40sap.com%7Cf16cfd102268469fd0c808dbe37ab856%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638353888443816792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2jPvrWOGpFT%2FO50MV4eDiCy5pDOC50SgUOv2noq3T%2F8%3D&reserved=0<https://w3c.github.io/rdf-star/implementations.html>
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Frdf-star%2Fimplementations.html&data=05%7C01%7Cfelix.sasaki%40sap.com%7Cf16cfd102268469fd0c808dbe37ab856%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638353888443816792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2jPvrWOGpFT%2FO50MV4eDiCy5pDOC50SgUOv2noq3T%2F8%3D&reserved=0<https://w3c.github.io/rdf-star/implementations.html>>
>
> Best,
>
>
> Felix
>
> *Von: *Gregg Kellogg <gregg@greggkellogg.net>
> *Datum: *Samstag, 11. November 2023 um 21:23
> *An: *Adrian Gschwend <adrian.gschwend@zazuko.com>
> *Cc: *public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
> *Betreff: *Re: Next weeks discussions and decision-making for RDF Star WG
>
>
>
> Sie erhalten nicht oft eine E-Mail von gregg@greggkellogg.net. Erfahren Sie,
> warum dies wichtig ist <https://aka.ms/LearnAboutSenderIdentification>
>
>
>
> I think it’s great to focus on resolving this fundamental issue. Below are the
> outlined suggestions with some additional thoughts:
>
> 1) Do nothing beyond RDF 1.1, there’s already a reification vocabulary with
> native support in RDF/XML
>
> 1.1) Same as above, but add syntactic sugar to Turtle/TriG/SPARQL for
> expressing reified statements. This would most naturally involve using a blank
> node subject, rather than a fragment identifier. Something based on the
> current quotedTriple syntax ‘<<‘ qtSubject predicate qtObject ‘>>’ could be
> syntactic sugar for [ a rdf:Statement; rdf:subject qtSubject; rdf:predicate
> predicate; rdf:object qtObject ]. (Stable identification can be addressed via
> indirection such as <#frag> rdfx:instanceOf <:a :b :c >).
>
> 2) Declare victory using the current tripleTerm resource. Triples are types,
> and something like rdfx:instanceOf can be used to derive tokens.
>
> 3) Leverage RDF 1.1 named graphs with the provision that a blank node graph
> name used elsewhere as a subject or object “identifies" that graph so named
> (with some work on what “identifies” means in this context). This is
> effectively how JSON-LD is used in Verifiable Credentials and elsewhere. A
> graph inclusion hierarchy, if required, can be derived by following the path
> from subject/object to graph name/graph.
>
> 4) Create a graphTerm resource where graphTerms are first-class terms and are
> distinct from named graphs. This is probably closest to how Notation3 uses
> graphs. This is arguably the purist from a logic point of view, but may be
> more difficult to express in abstract and concrete syntaxes.
>
> Frankly, I think any of the single triple use cases can be expressed using
> either of these paradigms; collections of triples require one of the
> graph-based solutions. The main issue that gets in the way of settling on this
> is the Type/Token debate. I think this can be resolved in other ways. This
> doesn’t attempt to consider transparency/opacity; for blank nodes, I think
> opacity can be solved at the syntax level, by using identifiers that don’t
> overlap.
>
> Consider the URL https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fxmlns.com%2Ffoaf%2F0.1%2FPerson&data=05%7C01%7Cfelix.sasaki%40sap.com%7Cf16cfd102268469fd0c808dbe37ab856%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638353888443816792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jqVz7OtJRp8FeWGDnH0%2BSopVDVmJozu6vyJ%2BDe5jwPQ%3D&reserved=0<http://xmlns.com/foaf/0.1/Person>
> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fxmlns.com%2Ffoaf%2F0.1%2FPerson&data=05%7C01%7Cfelix.sasaki%40sap.com%7Cf16cfd102268469fd0c808dbe37ab856%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638353888443816792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jqVz7OtJRp8FeWGDnH0%2BSopVDVmJozu6vyJ%2BDe5jwPQ%3D&reserved=0<http://xmlns.com/foaf/0.1/Person>>. It could be considered to denote an RDF
> document containing a vocabulary definition for foaf:Person. It can be
> considered to be both a type and a token, depending on how it is used. In the
> context of the vocabulary definition, it is a token against which other
> properties can be defined:
>
>     foaf:Person a rdfs:Class; rdfs:label “Person”; …
>
> In another context, it is a type:
>
>     <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Frdfweb.org%2Fpeople%2Fdanbri&data=05%7C01%7Cfelix.sasaki%40sap.com%7Cf16cfd102268469fd0c808dbe37ab856%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638353888443816792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ctP8eMgSC6gAjCqpC1gCYvyf5WLCihVDBDfq%2FIe4r48%3D&reserved=0 <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Frdfweb.org%2Fpeople%2Fdanbri&data=05%7C01%7Cfelix.sasaki%40sap.com%7Cf16cfd102268469fd0c808dbe37ab856%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638353888443816792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ctP8eMgSC6gAjCqpC1gCYvyf5WLCihVDBDfq%2FIe4r48%3D&reserved=0<http://rdfweb.org/people/danbri>>> a
>     foaf:Person; foaf:name "Dan Brickley” ...
>
> Similarly, a graphTerm could be considered to be a type or a token, depending
> on the context in which it is used. Something like {:a :b :c} a rdf:Graph has
> the characteristic of a type, while {:a :b :c} ex:containedIn
> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Ffoo&data=05%7C01%7Cfelix.sasaki%40sap.com%7Cf16cfd102268469fd0c808dbe37ab856%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638353888443816792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=INgedr8F17iD3SbMQ%2BSQ5zKGlYlQV2GsGYZD9LcPZao%3D&reserved=0 <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Ffoo&data=05%7C01%7Cfelix.sasaki%40sap.com%7Cf16cfd102268469fd0c808dbe37ab856%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638353888443816792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=INgedr8F17iD3SbMQ%2BSQ5zKGlYlQV2GsGYZD9LcPZao%3D&reserved=0<http://example.com/foo>>> has the characteristic of a
> token. We can leverage rdfs:range/domain and explicit type declarations to
> clarify the intended meaning.
>
> Perhaps we can use other explicit or implicit typing to clarify the use cases
> about when we are identifying a specific statement within a graphTerm or the
> graph itself as a collection of statements.
>
> Regarding the different possibilities outlined above: RDF is a system for
> describing graphs/datasets composed of triples/statements. IMHO, the
> fundamental building block should be a graph, so I favor either leveraging
> named graphs or adding a top-level graphTerm (options 3 and 4 above). I think
> the impact on implementations, such as quad stores, favors reusing and
> refining the RDF 1.1 concept of named graphs, but with nuance given to graphs
> named by blank nodes. This also works as is with N-Quads. Representing
> graphTerms natively requires some form of syntactic extension (either embedded
> graphs, or a new space for graph identifiers) as well as defining a graphTerm
> similar to how we’ve already defined a tripleTerm in the abstract algebra.
>
> If the WG is not able to take on the work for describing such use of named
> graphs, then I would favor doing something more like 1.1: reuse the existing
> reification vocabulary with syntactic sugar from the quotedTriple production
> of Turtle/TriG and SPARQL rather than adding a new tripleTerm which could
> interfere with future groups to take on the work of better describing the use
> of graphs as resources. But, I’m happy to go along with the consensus of the
> group whatever we decide.
>
> Gregg Kellogg
> gregg@greggkellogg.net
>
>
>
>     On Nov 10, 2023, at 8:42 PM, Adrian Gschwend <adrian.gschwend@zazuko.com>
>     wrote:
>
>     Dear all,
>
>     Following our last meeting and discussions on the various proposals, it
>     has become clear that we need to focus our efforts on choosing a specific
>     direction for our next steps. To facilitate our decision-making process,
>     we are asking all members to review the proposals in detail and consider
>     which one they currently favor. This preliminary decision will help to
>     make the discussion at our next meetings more structured and productive.
>
>     The next meeting is on November 16, as discussed for once we start at the
>     normal time but stay one hour longer. Please see the calendar for details,
>     the event is updated.
>
>     regards
>
>     Ora & Adrian
>     --
>     Adrian Gschwend
>     CEO Zazuko GmbH, Biel, Switzerland
>
>     Phone +41 32 510 60 31
>     Email adrian.gschwend@zazuko.com
>