Re: Moving to standard track?

I see the advantages of a narrow approach, but we need to settle on whether we’re creating a new specification (“fork”) or updating existing specifications (“update”). RDF-star relates to several different specs and this needs to be carefully considered. 

Regarding other features, I don’t think we’ll ever see a WG chartered specifically to deal with text direction; in the json-ld WG the presumption was that a future WG chartered to update the RDF specs could included this. Indeed, it may be necessary to get past the internationalization wide review. 

Gregg Kellogg

Sent from my iPad

> On May 6, 2021, at 11:44 PM, Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu> wrote:
> 
> 
> 
> 
> 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> 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> 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
>>