W3C home > Mailing lists > Public > public-rdf-star@w3.org > August 2019

Re: RDF* semantics

From: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Date: Fri, 30 Aug 2019 16:43:34 -0400
Message-Id: <47BEFC4E-22C3-4A60-8920-C7A1E028B41B@openlinksw.com>
To: public-rdf-star@w3.org
Olaf, Kingsley, others --

Perhaps instead of the overloaded ex:claims predicate now 
being hammered at, and I think distracting from the meatier
subjects at hand, you might switch to using an example 
predicate like ex:asserts which local-part is at least 
*less* over-loaded and hopefully therefore more clearly 
and intuitively understood?

I am suggesting this in significant part because I like 
to think and speak of triples/quads as assertions, which 
obviously have provenance (e.g., the asserter, at a place, 
at a time, in a document), among other attributes.

I dislike thinking or speaking of triples/quads as facts, 
because facts do not typically have provenance as such -- 
they simply *are* -- and because triples/quads can be just 
as easily used to encode falsehoods and nonsensicals as 
truths (e.g., 

   { PREFIX  ex:  <#>
     ex:the_sea  ex:is    ex:boiling_hot . 
     ex:pigs     ex:have  ex:wings .

and the simple (ahem) fact that such statements have been 
encoded as triples/quads should not be sufficient to 
indicate that they are (or ever have been, or ever will 
be) true -- nor even *asserted* to be true.

(I might, for instance, encode a number of falsehoods as 
triples within a named graph, which is then used to test 
whether other named graphs should be considered more or 
less trustworthy, based on the number of such falsehoods 
contained in the graph under test.)

(Who is this "Ted" guy?  I've been employed by OpenLink
Software, working with Kingsley et al since late 2000, and 
involved in a number of W3 XGs, CGs, and WGs in that time.  
Recent highlights include late-term co-chairing of the 
SHACL WG, and active contributions to the Verifiable Claims 
WG and the Credentials CG.)



Received on Friday, 30 August 2019 20:44:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:56 UTC