RE: Moving to standard track?

“I am afraid that keeping RDF and RDF-star different would only fragment the ecosystem, and increase the perceived complexity of the RDF ‘stack’."

I agree. Eventually the two need to be harmonized/merged.

Jonathon Storm
Pronouns: traditional (he, him, his)
Lead Data Architect, Core Data Architecture, S&P Global Market Intelligence

S&P Global
Mobile: 757-284-7786
jonathon.storm@spglobal.com<mailto:jonathon.storm@spglobal.com>
www.spglobal.com<http://www.spglobal.com/marketintelligence>

From: Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>
Sent: Friday, May 7, 2021 2:44 AM
To: public-rdf-star@w3.org
Subject: Re: Moving to standard track?



On 06/05/2021 23:08, Kingsley Idehen wrote:
On 5/6/21 9:21 AM, Dan Brickley wrote:


On Thu, 6 May 2021 at 10:37, Andy Seaborne <andy@apache.org<mailto:andy@apache.org>> wrote:


On 05/05/2021 19:51, Gregg Kellogg wrote:
>> On May 5, 2021, at 12:47 AM, Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu<mailto:pierre-antoine.champin@ercim.eu>> wrote:
>>
>> Hi all,
>>
>> TL;DR: I propose we discuss the move to standard track during our next call (Friday 2021-05-07, 3pm UTC)

Good plan.

>>
>> I had a discussion on Monday with Ivan Herman and a number of other people from the W3C team. I told them that my goal was to wait until we polish the CG report and get more implementation reports to initiate the chartering process. The encouraged me, instead, to not wait and start right now. Their arguments were the following:
>>
>> * the process of drafting a charter, getting it approved by W3C, and starting the working group, can be long; so we'd better start it now, and continue our CG work in parallel;
>>
>> * the charter will of course cite our CG report as an input for the future WG; waiting for that report to be more mature may give the impression that we expect the WG to merely rubber stamp the work that we have done, and this is not what WGs are for (and thus, giving this impression may antagonize some W3C members).
>>
>> A consequence of the latter point, which Ivan and others emphasized, is that we must be prepared to accept that the WG make some changes (possibly significant ones) to our spec. That is, of course, if the participants of the WG think it is the best way to go. If we are not ready for that, we should probably stop at the CG-report.
>
> A draft charter to update RDF, should also consider things like text direction as addressed in the JSON-LD WG. I hope it would be in-scope to consider adding semantics to Named Graphs, too, so that the name of a graph used elsewhere in the document would have some normative relationship to the graph it names.

I don't think coupling to a general RDF working group is the best way to
proceed. There is a difference of timescales.

The RDF-star work has an initial report, test suite, and this
community's discussions. It can move on a relatively short (for a WG)
timescale.

Other matters - all of which are good - are not at he same stage and
need input material, or to run on a longer-timescale so that wider,
in-depth discussions can happen and become proposals.

+1

RDF-star is clearly a significant phenomena in this space, and has a refreshing level of engagement with implementors. Whether it (or something very like it) is the future of RDF is another thing. Getting a WG to tidy up and bless it as-is will be 1,000,000 times easier if it is its own thing, rather than carrying the larger burden of being "the next version of RDF".

Dan


+1

RDF-Star is its own thing.

It isn't the next version of RDF.

I agree with Dan that we should keep the focus of the WG narrow enough (although, as stated in my initial email, we should be prepared for the WG to make significant changes to our spec, not necessarily to "bless it as-is").

But I am not sure what you (Dan and Kingsley) mean by "not the next version of RDF"... It is definitely not RDF 2.0, but the way I see it, it is an evolution of the RDF model, not a distinct thing (and I think this view is shared by many people working on the CG report).

I am afraid that keeping RDF and RDF-star different would only fragment the ecosystem, and increase the perceived complexity of the RDF "stack".

  pa

--

Regards,



Kingsley Idehen

Founder & CEO

OpenLink Software

Home Page: http://www.openlinksw.com


Community Support: https://community.openlinksw.com


Weblogs (Blogs):

Company Blog: https://medium.com/openlink-software-blog


Virtuoso Blog: https://medium.com/virtuoso-blog


Data Access Drivers Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers




Personal Weblogs (Blogs):

Medium Blog: https://medium.com/@kidehen


Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/


              http://kidehen.blogspot.com




Profile Pages:

Pinterest: https://www.pinterest.com/kidehen/


Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen


Twitter: https://twitter.com/kidehen


Google+: https://plus.google.com/+KingsleyIdehen/about


LinkedIn: http://www.linkedin.com/in/kidehen




Web Identities (WebID):

Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i


        : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this




________________________________

The information contained in this message is intended only for the recipient, and may be a confidential attorney-client communication or may otherwise be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please be aware that any dissemination or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the message and deleting it from your computer. S&P Global Inc. reserves the right, subject to applicable local law, to monitor, review and process the content of any electronic message or information sent to or from S&P Global Inc. e-mail addresses without informing the sender or recipient of the message. By sending electronic message or information to S&P Global Inc. e-mail addresses you, as the sender, are consenting to S&P Global Inc. processing any of your personal data therein.

Received on Friday, 7 May 2021 10:09:20 UTC