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

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

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