due 24 Mar 2023

due 23 Mar 2023

As an specification editor,
I want to be able to refer to the concept of a graph or dataset not including quoted triples,
So that algorithms such as that defined in RDF Dataset Canonicalization can be written to so as to not depend on the concept of triples as a resource (quoted triples).

This concept has been described as an "RDF 1.1 Dataset", but that may not include other desired components of an RDF 1.2 Dataset, hypothetically including support for text direction or other concepts other than embedded/quoted triples.

due 27 Apr 2023

due 13 Jan 2023

due 24 Mar 2023

As suggested by @pfps (w3c/rdf-schema#10):

My suggestion for resolving the issue would be to add something to the comment for the datatype to the effect that rdf:PlainLiteral is no longer used in RDF itself, but that it continues to be part of RIF and OWL 2. But that isn't much of a change from the wording that is already there.

And I agree with the opinion.

due 16 Feb 2023

Peter F. Patel-Schneider
Ora Lassila
Vladimir Alexiev

Interested non-WG members:

Thomas Lörtsch

due 16 Mar 2023

I propose that we add a prefix of the form [NameOfTaskForce] to the topic of a new email thread when it is specific to the task force called NameOfTaskForce. This issue is to get a unique proposal of what prefixes to use for each task force and enforce their use by the WG, so as to simplify filtering those discussions or finding them in the future. Here is a proposal:

• Use case task force: [UC] (clear, short, hardly possible to misspell it)
• Semantics task force: [Sem] (rather clear, short and hard to misspell)
• Editors task force: [ED] (somewhat clear, short and hardly possible to misspell)

Alternative:

• Use case TF: [UC]
• Semantics TF: [Semantics] (very clear but long and easy to misspell)
• Editors TF: [Editors] (very clear but possible to misspell)

There are two notes in the RDF Concepts drafts on Entailment and Equivalence that they are similar to the terms entails and equivalent in semantics.

Which is the appropriate primary definition?

Should one simply be a reference to another (e.g., <dfn data-cite=".RDF12-CONCEPETS#dfn-entailment">entails</dfn>)?

If parallel definition is appropriate, they should probably cross-reference each other and note subtlties.

As it is now, both specs will export these terms making them show up in xref to allow automatic resolution. Existing identifiers can be preserved in documents without exporting them (e.g., <span id="..></span>, or <dfn class="no export"></dfn>.

Probably at some point we should automate finding parallel term definitions in different specs which should be unified.

(ghurlbot failed to create this action during the 2023-02-23 meeting)

We are working a new specification for a binary format using IETF CBOR called "Gordian Envelopes". We are planning to submit this spec for Gordian Envelopes that leverages deterministic CBOR as an IETF Internet-Draft by end of the week:

ABSTRACT: The envelope protocol specifies a format for hierarchical binary data built on CBOR. Envelopes are designed with "smart documents" in mind, and have a number of unique features including easy representation of semantic structures like triples, built-in normalization, a built-in Merkle-like digest tree, and the ability for the holder of a document to selectively encrypt or elide specific parts of a document without invalidating the digest tree or cryptographic signatures that rely on it

https://blockchaincommons.github.io/WIPs-IETF-draft-envelope/draft-mcnally-envelope.html

In particular for this group, it supports triples where both the predicates and objects can be fully nested, i.e. "envelopes in envelopes". Part of the goal for this was to support annotation to allow for semantic clarity of both.

As I understand it, this approach comes closest to RDF* in approach, as it is more that a LPG (labeled property graph). Gordian Envelopes are, however, ONLY a data format, it does not specify or require semantic data.

We have a high-level overview of Gordian Envelops at:

https://www.blockchaincommons.com/introduction/Envelope-Intro/

A more engineering-level introduction at:

https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Envelope-Tech-Intro.md

We have a video playlist starting with a 10m high-level introduction:

https://www.youtube.com/playlist?list=PLCkrqxOY1FbooYwJ7ZhpJ_QQk8Az1aCnG

We have a reference CLI implementation (written in Swift) available now, and some of our patrons have begun porting libraries to more languages like Kotlin, Typescript, Python, and Blockchain Commons is also committed to porting to Rust as funding allows. Let us know your needs!

For those of you who don't like videos, we have an annotated introduction to our CLI reference implementation that really demonstrates of the power of CBOR with Gordian Envelopes:

https://github.com/BlockchainCommons/envelope-cli-swift/blob/master/Transcripts/1-OVERVIEW-TRANSCRIPT.md

I'm seeking someone with a greater familiarity with RDF* architectures to identify if Gordian Envelopes might be useful to this community.

cc/ @wolfmcnally @selfissued @drummondreed

Please forgive the built-in bias of this issue.

GitHub wiki is tragically under-featured. Major lacks that I run into start with these:

• There is no "alert" mechanism associated with GitHub wiki pages, so the only way to discover that a wiki page has been updated is to visit the page.
• There is no comparison across page versions, so you cannot see what changes have been made, for instance, since your last visit, nor since the last edit you know you saw, nor between this version and the previous, etc.

I have not yet encountered a feature that GitHub Wiki has that other Wikis lack.

Historically, all W3 WGs (and various other W3 entities) were automatically (whether by human or bot, I don't know) assigned a homepage within the overarching W3 Wiki, which is a fully-fledged wiki, which does provide all the things that the GitHub wiki fails to provide.

I strongly advise and request that we consider moving the RDF-star wiki work from the GitHub wiki to the W3 wiki.

due 2 Jan 2023

due 13 Jan 2023

due 9 Mar 2023

per https://www.w3.org/2023/03/30-rdf-star-minutes.html#a01

due 16 Feb 2023

due 16 Mar 2023

due 22 Dec 2022

This repo needs to be kicked off with a README, CODEOWNERS, etc., and to be added to RDF-star WG Tools.

RDF-star WG meetings need to be added to the W3 Calendar.

We are chartered 2022-08-29 thru 2024-08-28, and we've already burned 1.5 months in silence, contrary to the Charter Timeline.

Also, somehow we only have 11 official WG participants (from only 7 organizations) for something that appeared to have significantly more interest (though about the same number of active concall attendees) while it was in CG. Extra strange, the second chair listed on the charter is not listed as a WG participant!

due 9 Feb 2023

due 19 Jan 2023

due 9 Mar 2023

due 16 Mar 2023

due 9 Mar 2023

https://www.w3.org/2023/03/30-rdf-star-minutes.html#a02

due 13 Apr 2023

This issue is for discussion and tracking work to convert SPARQL 1.1 specifications to ReSpec (or decide not to convert a spec).

They are all mentioned in the RDF-star charter.

• Overview
• Query
• Update
• Service Description
• Federated Query
• Query Results JSON Format
• Query Results CSV and TSV Formats
• Query Results XML Format (Second Edition)
• Entailment Regimes
• Protocol
• Graph Store HTTP Protocol

Many of the specs were written in XML, to produce HTML via a W3C XSLT pipeline.

This means that while the HTML is "not pretty", it is quite regular.
Using HTML tidy produces HTML that is better for editing.

Hopefully, a basic bulk conversion can be done by automation.

due 23 Feb 2023

All the labels in our multiple repositories have been inherited from other W3C repos, because many of them are common and have meaning outside the repos (e.g. labels for horizontal reviews).

Among those labels are 3 which are used by the errata management page creaed by @iherman (see example here): ErratumRaised, Errata and Editorial.

The latest is super confusing, because people tend to use it to mark other issues or PRs with it, while other labels should be used (e.g. spec:editorial). See example in https://w3c.github.io/json-ld-syntax/errata/

I propose to:

• rename these 3 labels with a prefix, following practice in other labels: errata:raised, errata:confirmed, errata:editorial;
• adapt @iherman 's code when (if) we adopt it, to use these tags instead of the original ones.

This would make our list of labels more consistent and, hopefully, easier to use.

due 2 Feb 2023

Based on the list of #10, we want to track who volunteers to work on what spec(s). If you work on a spec, please add your name in the form of - @username so we have it properly indented

• https://github.com/w3c/rdf-new
  • @rdfguy
• https://github.com/w3c/rdf-concepts
  • @gkellogg
  • @hartig
  • @pchampin
  • @afs
• https://github.com/w3c/rdf-primer
  • @pchampin
• https://github.com/w3c/rdf-schema
  • @domel
  • @timothee-haudebourg
• https://github.com/w3c/rdf-semantics
  • @pfps
  • @doerthe
  • @timothee-haudebourg
  • @franconi
• https://github.com/w3c/rdf-n-quads
  • @gkellogg
  • @domel
• https://github.com/w3c/rdf-n-triples
  • @gkellogg
  • @domel
• https://github.com/w3c/rdf-trig
  • @gkellogg
  • @domel
• https://github.com/w3c/rdf-turtle
  • @gkellogg
  • @domel
• https://github.com/w3c/rdf-xml
  • @gkellogg
• https://github.com/w3c/sparql-new
  • @rdfguy
• https://github.com/w3c/sparql-concepts
  • @afs (interim)
• https://github.com/w3c/sparql-query
  • @afs
  • @kasei
  • @hartig
  • @rubensworks
  • @Tpt
• https://github.com/w3c/sparql-update
  • @rubensworks
  • @afs
  • @Tpt
• https://github.com/w3c/sparql-service-description
  • @kasei
  • @rubensworks
• https://github.com/w3c/sparql-federated-query
  • @kasei
  • @hartig
• https://github.com/w3c/sparql-results-json
  • @afs
  • @kasei
  • @rubensworks
  • @Tpt
• https://github.com/w3c/sparql-results-csv-tsv
  • @kasei
  • @rubensworks
  • @Tpt
• https://github.com/w3c/sparql-results-xml
  • @domel
  • @rubensworks
  • @Tpt
• https://github.com/w3c/sparql-entailment
  • @pfps
• https://github.com/w3c/sparql-protocol
  • @afs
  • @kasei
  • @rubensworks
  • @Tpt
• https://github.com/w3c/sparql-graph-store-protocol
  • @afs
  • @Tpt

A number of open issues were compiled by the CG:
https://github.com/w3c/rdf-star/issues

They should be resolved and/or moved to the repositories of the WG.

Terms created via <dfn become exported and can be automatically reconciled by other specifications. Between RDF Concepts and Semantics a number of terms are created, and sometimes overlap.

• It's possible to "define" a term but reference a term from another spec using data-cite. For example, <dfn data-cite="RDF12-CONCEPTS">RDF graph</dfn>, which styles the term in the defining spec, and allows simple references such as <a>RDF graph</a>.
• Terms intended to be used locally can be declared to not be exported, for example <dfn class="no-export lint-ignore" data-dfn-for="rdf">invalid</dfn> (which comes from w3c/rdf-semantics#13).
• Former terms can be demoted, but should have an anchor so that any existing references will continue to resolve. For example <dfn class="export">invalid</dfn><span id="dfn-invalid.x"><!-- obsolete term --></span>.

Given the potential range of updates, we should consider what to do about the following terms:

• Denote – defined in RDF12-CONCEPTS and in RDF12-Semantics. Also Denotation in Semantics.
• Entailment – defined in RDF12-CONCEPTS and as Entail in Semantics
• Equivalent – Defined as Equivalence in Concepts and Equivalent in Semantics.
• Referent – defined in RDF12-CONCEPTS and in RDF12-SEMANTICS

Many other terms in Semantics are exported but not used, at least in RDF Semantics (e.g., rdfs13. We might consider just making these "no-export" and just preserve the anchor.

Thus far, SPARQL doesn't export any terms, but probably will at some point.

• RDF Term
• Simple Literal – Obsolete now, but matches simple literal in RDF Concepts.
• RDF Dataset

due 4 Feb 2023

due 9 Feb 2023

due 1 Jun 2023

The specification of canonical N-Triples is silent about the datatype of xsd:string literals. More specifically :

    "hello world"

and

   "hello world"^^<http://www.w3.org/2001/XMLSchema#string>

are equivalent terms in N-Triples and N-Quads, and the spec does not say which one should be used as the canonical form.

This has an impact on the RCH working group (w3c/rdf-canon#66).

due 23 Dec 2022

RESPEC creates index entries for all data-cites even if the cite is to a section, as in Section 5. There should be a way to remove these index entries.

due 11 May 2023

due 15 Feb 2023

Many working group documents have had CSS changes applied to them, for example w3c/rdf-turtle#20, which include code like:

    @media (max-width: 850px) {
        table th, table td { font-size: 12px; padding: 3px 4px;}
        table.ex th, table.ex td {overflow-x: scroll; max-width: 42vw !important;}

This change has the effect of reducing the side of text in tables when window width falls below a 850px, which occurs in many situations, not just on small devices. The reduced size makes it harder to read tables. In at least some cases there is no benefit to reducing the text size as the table can be rendered with no problems without reducing the text size.

Here is a screenshot showing the size difference.

Note how when the body text is small but easily readable the text in the table is less readable. There is no reason to reduce the table text size here as the table can be rendered at this width with no problems.

due 16 Feb 2023

due 30 Mar 2023

https://www.w3.org/mid/[email protected]

due 13 Apr 2023

As it says on the tin, any and all instances of MIME should be replaced media as appropriate for the local context.