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

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

BTW this isn't just about metadata. 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. 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.

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

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 02:00:01 UTC