Re: Toward easier RDF: a proposal

On 11/27/18 4:10 AM, Graham Klyne wrote:
> On 27/11/2018 08:47, Pat Hayes wrote:
>> Well, they might be able to draw conclusions and perform 
>> processing which goes
>> beyond the rather elementary semantics, perhaps making 
>> assumptions which cannot
>> be encoded directly in RDF itself (such as various closed-world 
>> assumptions
>> about uniqueness of naming or completeness of data) but this is 
>> not incompatible
>> with the official semantics, and may indeed rely on it in some 
>> ways. The notion
>> of semantic extension is designed to allow for this kind of 
>> external
>> non-RDF-sanctioned processing of RDF data. But I do not know of 
>> any examples of
>> such processing which /denies/or contravenes the RDF semantics. 
>> Do you?
> I'm not sure if this counts as an example...
> I fell foul of this in some software I was working on circa early 
> 2000's:  in that case, I noticed in time and adjusted my designs 
> accordingly, but the experience showed me that being aware of RDF 
> semantics can be important if data merging on a scope wider than 
> the immediate application is to be meaningful.
> It's a long time ago, and I forget the details, but it was to do 
> with modeling and implementing network devices and access 
> controls.  I do remember that my initial design (unintentionally) 
> involved non-monotonicity - adding a triple could make an 
> expression True that was previously False.

That way round is OK. Usually nonmonotonicity means making 
something false that was previously true, and doing this by 
adding information rather than deleting or modifying it. For RDF 
the troublesome case would be where G rdf-entails T, but a 
supergraph H of G does not entail T. I have never seen an example 
of that, though I guess it could happen if one tried to make the 
RDF be a kind of dynamic simulation of something with a changing 
state, which would of course be a terrible way to mis-use RDF.


> #g

call or text to 850 291 0667

Received on Tuesday, 27 November 2018 15:41:08 UTC