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

Links:

[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 *)

[3]
https://lists.w3.org/Archives/Public/public-rdf-star/2019Aug/0003.html
-- My earlier comments about this matter


Kingsley

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

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