W3C home > Mailing lists > Public > public-rdf-star@w3.org > October 2020

Re: owl:sameAs/referential opacity Re: Can RDFstar be defined as only syntactic sugar on top of RDF (Re: weakness of embedded triples)

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Fri, 30 Oct 2020 09:59:56 -0400
To: public-rdf-star@w3.org
Message-ID: <8a33b40f-4661-8f8a-1325-1e653c9d22a4@openlinksw.com>
On 10/29/20 11:00 PM, Holger Knublauch wrote:
> Maybe a way forward is to raise a GitHub ticket along the lines of "Do
> we want something like RDF* to become a W3C standard" and wait for
> votes. If it gets shot down (however this can work) then let's see if
> the various implementers (RDF4J [1], Jena [2] etc) will remove it again.
> BTW this seems to be off-topic from where this thread started, so at
> minimum I suggest a different thread.
> Holger
> [1] https://rdf4j.org/documentation/programming/rdfstar/
> [2] https://jena.apache.org/documentation/rdfstar/

A thread already exists titled "Are the names RDF* and SPARQL* worth the
confusion?" [1].


[1] https://lists.w3.org/Archives/Public/public-rdf-star/2020Oct/0049.html

[2] http://www.semantic-web-journal.net/system/files/swj1791.pdf --
Evaluation of Metadata Representations in RDF stores (* A good read *)

-- My earlier comments about this matter


> On 10/30/2020 12:48 PM, Kingsley Idehen wrote:
>> On 10/29/20 9:59 PM, Holger Knublauch wrote:
>>> On 10/30/2020 10:39 AM, Kingsley Idehen wrote:
>>>> On 10/29/20 7:54 PM, Holger Knublauch wrote:
>>>>> Yes exactly. We are all thinking out loud here and the outcome is
>>>>> likely going to be some glued-on patch that isn't going to be perfect
>>>>> from a theoretical POV. But the fact that RDF is already widely used
>>>>> and implemented is an opportunity, not a problem.
>>>> Hi Holger,
>>>> We have an opportunity to make RDF less confusing, and that's achieved
>>>> via clarity.
>>>>   From my vantage point, here's the problem:
>>>> Just as we reached a point where RDF understanding was gaining
>>>> traction,
>>>> along come both RDF* and SPARQL* to muddy the waters.
>>> Or: just as we reached a point where RDF was gaining traction, along
>>> came Property Graphs with built-in support for property edges. And
>>> they also took market share away, partly because of that.
>> No how I see it.
>> Data Integration, Verifiable Identity, and Privacy in general are
>> fundamental problems uniquely solved by Entity Relationship Graphs
>> constructed from RDF and deployed using Linked Data principles.
>> RDF isn't about Data Silos, and it is simply a superior solution to real
>> problems.
>> Property Graphs tell a story.
>> RDF can tell a deeper story that's actually much more useful. Let's give
>> it a chance.
>>> Not every RDF vendor must support RDF*, just like not every vendor
>>> supports OWL 2 or SHACL. Time will tell and people will vote with
>>> their feet.
>> None of that justifies clouding RDF in confusion.
>>> At least those that do see enough benefits in these features should
>>> have a shared spec to start with, because what we have seen in the
>>> last two years is many different ad hoc implementations.
>> None of that warrants adding "*" to an existing standard and then
>> generating confusion.
>> Many on this list understand what Syntax Sugar is, that isn't the case
>> when dealing with customers and prospects. In short, some might find the
>> Syntax Sugar explanation defensive etc..
>>> I can confirm that many of our customers do like the features of
>>> proper reification in practice. The previous alternatives such as
>>> rdf:Statements were not good enough IMHO.
>> I can confirm we have customers doing fine with SPARQL Named Graphs or
>> Reified RDF statements etc..
>> When folks talk to me about Property Graph I just get to the heart of
>> the matter by helping them understand the following:
>> 1. Every Graph isn't a Network -- since all the connections aren't
>> transitive in nature
>> 2. Every Network is a Graph constructed from connections that are
>> transitive in nature
>> Then I demonstrate how you can perform Network Analytics on an RDF-based
>> Entity Relationship Graph using SPARQL and Transitivity
>>> BTW this isn't just about metadata.
>> As per the doc I shared, and my very early comments in this forum, it is
>> about metadata since I regard describing documents or named graphs
>> metadata creation endeavors.
>> If two documents contain conflicting birthdays for an individual I can
>> use the description of one document as the basis for crafting a solution
>> that determines the preferred source of birthday information. The same
>> applies to issues such a relationship time duration, and many of the
>> other examples knocked up by the Property Graph promoters.
>>> One use case that we like is to attach sh:severity and sh:message,
>>> possibly sh:deactivated to SHACL constraint triples. Right now these
>>> can only be stored per shape, but that is very verbose and causes an
>>> explosion of unnecessary shapes.
>>> Without a W3C spec for something like RDF* there is no way that a
>>> future SHACL version could include such a nicer syntax.
>> Again, verbosity isn't the basis for tacking on "*" to RDF or SPARQL
>> with verbosity-hiding Syntax Sugar as the solution.
>>> I do believe that such future specs would preface RDF*-specific
>>> features into special sections so that not every vendor needs to
>>> support those next-gen features either.
>> This is about clarity over confusion. Vendor implementations is a
>> distant second re issues of concern.
>>> I do agree that messaging matters and the name will matter, so instead
>>> of calling this a completely new language I think we should aim at
>>> representing this as a set of syntax conventions and optional
>>> extensions that do not break anything (unless someone loads TTL* files
>>> etc).
>> I don't have a problem with that, at least it doesn't create the kind of
>> confusion that concerns me right now :)
>> Kingsley
>>> Holger
>>>> If there were no existing solutions to expressing metadata that
>>>> describes data depicted as a graph that would be one clear problem,
>>>> but
>>>> that simply isn't the case [1].
>>>> How else does one describe the signage and surface combination
>>>> delivered
>>>> by an RDF graph and the document from which it originates? All
>>>> solutions
>>>> to this problem include some degree of verbosity if precision is the
>>>> quest.
>>>> This is neither RDF nor SPARQL, so why not give it a different name
>>>> and
>>>> spell out its syntax-sugar orientation clearly?
>>>> Links:
>>>> [1] http://www.semantic-web-journal.net/system/files/swj1791.pdf --
>>>> Evaluation of Metadata Representations in RDF stores


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/

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

Received on Friday, 30 October 2020 14:00:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 30 October 2020 14:00:16 UTC