W3C home > Mailing lists > Public > public-rdf-star@w3.org > May 2021

Re: Moving to standard track?

From: thomas lörtsch <tl@rat.io>
Date: Fri, 7 May 2021 15:27:11 +0200
Cc: "public-rdf-star@w3.org" <public-rdf-star@w3.org>
Message-Id: <CE2E2C51-71DF-4FE2-8EE6-B8778B6D8C13@rat.io>
To: "Lassila, Ora" <ora@amazon.com>
> On 7. May 2021, at 14:56, Lassila, Ora <ora@amazon.com> wrote:
> 
> I agree as well. The challenge now, I believe, is to charter a WG to only work on RDF-star, and not “oh hey, there are also these N other things we wanted to fix in RDF”.

This certainly sounds like the only reasonable way forward and I agree that we should try to charter the WG as succinct as possible! 

However there is for example that unfinished business with occurrences that also touches named graphs. How can we not try to solve that but still make sure that we don’t block a reasonable solution to be worked on later? I personally had to come up with my private solution to the named graph problem first before I could agree that what the current draft says about occurrences is good enough for now. 

So we probably should try to figure out how embedded triples relate to other constructs in RDF. During the last months such questions have often been dismissed as too RDF-2-ish, but my approaches where also, admitteldy, rather trying to solve those problems, not only describe their relation to RDF-star. But we could aim at a clear conceptualization of how embedded triples can fit in and interact with the rest of RDF, defining a sort of interface or "conceptual API". 

If understanding embedded triples as self-contained statement identifiers is indeed sufficiently precise and complete, that shouldn’t be too hard.
 
Thomas


> Ora
>  
> -- 
> Dr. Ora Lassila
> Principal Graph Technologist
> Amazon Web Services
> ora@amazon.com
>  
>  
> From: "Storm, Jonathon" <jonathon.storm@spglobal.com>
> Date: Friday, May 7, 2021 at 6:10 AM
> To: Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>, "public-rdf-star@w3.org" <public-rdf-star@w3.org>
> Subject: RE: [EXTERNAL] Moving to standard track?
> Resent-From: <public-rdf-star@w3.org>
> Resent-Date: Friday, May 7, 2021 at 6:09 AM
>  
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
>  
> “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
> www.spglobal.com
>  
> 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> 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
>  
>  
> 
> 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 13:27:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 7 May 2021 13:27:30 UTC