- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 30 Oct 2020 11:59:44 +1000
- To: public-rdf-star@w3.org
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