Re: Moving to standard track?

On 5/7/21 2:43 AM, Pierre-Antoine Champin 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
>>> <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   
>
Hi Pierre-Antoine,

RDF and RDF-Star are related, but different things.

As I see it, they are related by a desire to offer a syntax sugar that:

1. Negates the verbosity of Reification as defined in the RDF Vocabulary

2. Offers a compact syntax-sugar for expressing the properties of an RDF
sentence -- influenced by relationship labeling functionality offered
so-called Property Graph Databases

The reality, as I see it above, is difficult enough to explain
coherently in a forum comprising knowledgeable practitioners.

In my personal experience, I expect RDF and RDF-Star conflation (what
happens in the marketing realm) to ultimately reek havoc on RDF itself.

Remember, RDF already has a penchant for attracting confusion
(unfortunately!) while rarely receiving positive attribution for the
complex data-centric challenges that it handles both well and uniquely.

RDF-Star shouldn't be perceived (i.e. promoted) as an extension of RDF.
It is ultimately, a heuristic for handling a specific problem that has
little to do with RDF's actual data model.

A sentence is a sentence. You can't make a sentence do more than what it
was constructed to handle.

A document is where sentences live, it too has a special role in terms
of the context that it brings to bear re sentence interpretation.

*Simple example in plain English*

"Kingsley and Pierre-Antoine are RDF practitioners." is a sentence.
Temporal aspects of that sentence can be expressed in a variety of ways
without changing the fundamental nature and roles of sentences or the
documents within which they are created.

Modeling the sentence-example outlined above as a Graph doesn't change
the situation at hand.

RDF-Star, as I've always seen it, is simply trying to offer syntax-sugar
(via a heuristic) that's influenced by the perceived marketing-momentum
of a different genre of product that's based on a higher-level model
that's utterly inferior to RDF, as time will demonstrate.

BTW -- circa 2021, there is far more RDF on the Web
<https://twitter.com/search?q=%23SchemaOrg%20%23eCommerce%20%23RDF&src=typed_query&f=live>
than most assume. By that I mean, RDF as we all know it has already gone
past the point of critical mass and none of it includes or depends on
the issues RDF-Star is trying to address, IMHO.


*Conclusion*

RDF-Star and RDF are different things. Common model sharing is a
controversial perspective, IMHO.


Links:

[1]
https://twitter.com/search?q=%23SchemaOrg%20%23eCommerce%20%23RDF&src=typed_query&f=live
-- Sampling of RDF on the Web deployed via HTML

-- 
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