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

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/


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

Received on Friday, 30 October 2020 03:00:18 UTC