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://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://w3c.github.io/rdf-star/implementations.html 
> <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 http://xmlns.com/foaf/0.1/Person 
> <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:
> 
>     <http://rdfweb.org/people/danbri <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 
> <http://example.com/foo <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
>

Received on Sunday, 12 November 2023 12:22:55 UTC