Re: RDF* and grouping relation properties

> On Jun 21, 2020, at 5:14 AM, thomas lörtsch <tl@rat.io> wrote:
> 
> 
> 
>> On 18. Jun 2020, at 17:44, Tim Finin <finin@umbc.edu> wrote:
>> 
>> While experimenting with RDF* I realized one issue: for some relations, we may have several properties that should be treated as a group.  For example, the provenance of a relation extracted from the text of a web page might include a link to the page and the date retrieved.
>> 
>> Using the following two RDF* expressions merges the four properties so that we can no longer determine which :source and :retrieved values go together.
>> 
>> << :man :hasSpouse :woman >>
>>    :source <http://foo.com/>;
>>    :retrieved "2020-06-17"^^xsd:date .
>> << :man :hasSpouse :woman >>
>>    :source <http://bar.com/>;
>>    :retrieved "2020-01-01"^^xsd:date .
>> 
>> Using a traditional RDF reification approach maintains the pairing.
>> 
>> :man2 :hasSpouse :woman2 .
>> [ ]  a rdf:Statement ;
>>     rdf:subject :man2 ;
>>     rdf:predicate :hasSpouse ;
>>     rdf:object :woman2 ;
>>    :source <http://foo.com/> ;
>>    :retrieved "2020-06-17"^^xsd:date .
>> [ ] a rdf:Statement ;
>>    rdf:subject :man2 ;
>>    rdf:predicate :hasSpouse ;
>>    rdf:object :woman2 ;
>>   :source <http://bar.com/>;
>>   :retrieved "2020-01-01"^^xsd:date .
> 
> In my understanding of the RDF Standard Reification semantics your two blank nodes are owl:sameAs as the reification quad refers to the abstract triple type, not any concrete token.

Correct. But bear in mind that none of the semantic guidance in the RDF specs for reification is normative. RDF reification has /no/ normative semantics. 

The reason for this is that before the RDF WG had even convened, there were already several conflicting views about what it should mean, and I was not able to come up with one semantic story which could accomodate them all. I sketched a possible semantics which seemed to me to be the only one that could fully make sense. TimBL (and others) did not like this for the reason you mention, that it does not allow for things like provenance statements, but as there was not at the time any alternative, it was included - better than nothing? - but labelled as non-normative. 

> That contradicts the intuition of the provenance statements (:source and :retrieved) but that’s just how things are right now in RDF. There is no sound meta modelling in RDF.

The problem with a semantics which /would/ support provenance is that it would have needed to introduce a semantic notion of a single published instance of a triple, and no such notion had ever been considered. It would have introduced a large and not well-understood extension to the basic semantic framework of RDF, one that was rejected by the RDF WG as being too large a change to RDF. One can get a sense of what is needed by the subsequent work by Jeremy Carroll, Christian Bizer, Patrick Stickler and myself on the semantics of named graphs. (If anyone decides to try to read this, notice that the first thing it does is to distinguish between a named graph and an RDF graph.) 
> 
> It would of course be possible to define subclasses of rdf:Statement, like rdf:TripleType and rdf:TripleToken, define a context (e.g. a Named Graph) in which a triple becomes an actual token, and then reify such tokens. Only then the above provenance statements would have sound semantics.

Right.

> 
> To the best of my knowledge RDF* binds its reification semantics back to RDF Standard Reification. The RDF* <<…>> construct is syntactic sugar for the RDF Standard Reification quadlet - nothing more, nothing less [0]. So merging those provenance statements is indeed the right thing to do. One might even argue that RDF* has a slight advantage over RDF Standard Reification as it represents the semantics more faithfully. However not what anybody would expect from the solution to reification in RDF.

IMO, there is nothing useful that RDF* provides that could not be done better using the named graph vocabulary, with a solid semantics which also includes such things as notions of web publication, web speech acts and signed warrants. 

Pat

> 
> Thomas
> 
> 
> [0] Well, not exactly, as there are those modes too - SA and PG - which may implicitly add the cited triple to the graph or not. That’s a proposal and I’m not sure if implementations support mode switching or which mode(s) they support. 
> 
> 
> 
>> A possible solution when using RDF* is to encapsulate associated properties as a blank node entity, as in the following
>> 
>> :man3 :hasSpouse :woman3 .
>> << :man3 :hasSpouse :woman3 >>
>>    :provenance [ :source <http://foo.com/>;
>>                           :retrieved "2020-06-17"^^xsd:date ] .
>> << :man3 :hasSpouse :woman3 >>
>>    :provenance [ :source <http://bar.com/>;
>>                           :retrieved "2020-01-01"^^xsd:date ] .
>> 
>> However, this approach seems to violate the normal key/value pattern of property graph properties, which could be a compatibility issue.
> 
>> 
>> 
>> --
>> Tim Finin,  Willard and Lillian Hackerman Chair in Engineering,  Computer Science and
>> Electrical Engineering, U. Maryland, Baltimore County, 1000 Hilltop Circle, Baltimore MD
>> 21250. http://umbc.edu/~finin, finin@umbc.edu, tfinin@gmail.com, mobile:410-499-3522