RE: Proposed response for timbl-02 (reification semantics)

> -----Original Message-----
> From: ext Dan Brickley [mailto:danbri@w3.org]
> Sent: 10 April, 2003 10:15
> To: Stickler Patrick (NMP/Tampere)
> Cc: bwm@hplb.hpl.hp.com; gk@ninebynine.org; w3c-rdfcore-wg@w3.org
> Subject: Re: Proposed response for timbl-02 (reification semantics)
> 
> 
> * Patrick.Stickler@nokia.com <Patrick.Stickler@nokia.com> 
> [2003-04-10 09:51+0300]
> > > From: ext Dan Brickley [mailto:danbri@w3.org]
> > > write a test case (would be a new kind of test case for 
> us) that uses
> > > *OWL* semantics for inferring identity (eg. via 
> > > InverseFunctionalProperty).
> > > 
> > > The goal would be for inferences justified by the OWL 
> rules to cause
> > > 'annoying' onclusions involving the resources named by 
> > > rdf:predicate, :subject 
> > > or :object properties. We could even ask TimBL if he could 
> > > re-couch his 
> > > concerns about the semantics using such an approach...
> > > 
> > > I understand this would need a fwd reference to OWL, but 
> > > since it would be 
> > > a 'health warning' note for implementors rather than a formal 
> > > rdf core test
> > > case I don't see that as a problem.
> > 
> > Do you mean basically telling folks not to write rules that infer
> > things from reifications directly, but only from asserted triples?
> > 
> > If so, then I agree.
> 
> I didn't mean that, although that should also be discouraged. 
> 
> I meant something like the following:
> 
> (this to do with the De Re / De Dicto issue with rdf:predicate etc
> directly referencing the thing that is denoted by the 
> predicate etc of the
> reified statement, ie. not safely quoting it and hence 
> allowing substitution
> of coreferents)
> 
> here's a sketch towards testcase, sorry haven't polished this up but
> the intent should hopefully be clear. It takes your sample and 
> shows the kinds of interferences that OWL-happy systems might make in 
> the face of knowing some things have multiple URIs and OWLs ability to
> express equality, directly (sameFooAs) or indirectly 
> (InverseFunctionalProperty).
> 
> [[
>   _:s rdf:type rdf:Statement ;
>    _:s rdf:subject <s1> ;
>    _:s rdf:predicate <p1> ;
>    _:s rdf:object <o1> ;
>    _:s #source <http://some.server/some_schema.rdf>
> 
> <s1> owl:sameIndividualAs <s2>
> <p1> owl:sameIndividualAs <p2> 
> <o1> owl:sameIndividualAs <o2>
>    
> ...which with OWL semantics I believe gets us to:
>    
>    _:s rdf:type rdf:Statement ;
>    _:s rdf:subject <s2> ;
>    _:s rdf:subject <s1> ;
>    _:s rdf:predicate <p2> ;
>    _:s rdf:predicate <p1> ;
>    _:s rdf:object <o2> ;
>    _:s rdf:object <o1> ;
>    _:s #source <http://some.server/some_schema.rdf>
> 
> 
> which includes the subset of triples,
> 
>    _:s rdf:type rdf:Statement ;
>    _:s rdf:subject <s2> ;
>    _:s rdf:predicate <p2> ;
>    _:s rdf:object <o2> ;
>    _:s #source <http://some.server/some_schema.rdf>
>    
> which strongly suggests that the triple
> 
>    <s2> <p2> <o2> .
> 
> ...can be found in some_schema.rdf, rather than 'can be 
> deduced from...'.
> ]]
> 
> since the author of some_schema.rdf may know nothing about 
> those 3 uris,
> anyone defining predicates such as 'source' above which relate 
> a rdf:Statement and its parts 
> to documents etc should bed very careful with their
> definitions, to avoid mistakes. 

Well, I think that precluding inference based on reifications also
covers the above. I.e., you shouldn't have any reification statements
as part of an IF portion of an inference rule. And even if you had
those OWL equivalence assertions in the graph, if you avoid inferences
involving reifications, you won't end up with the dubious source
assertion

>    _:s rdf:type rdf:Statement ;
>    _:s rdf:subject <s2> ;
>    _:s rdf:predicate <p2> ;
>    _:s rdf:object <o2> ;
>    _:s #source <http://some.server/some_schema.rdf>

since to get that inferred statement, you'd have to have a reification
as a premise of your inference rule.

So it seems to me that so long as the warning is to avoid allowing
any of the reification vocabulary in the IF portion of rules, things
will be just fine.

Eh?

> Patrick, would it be possible for you to post your definition of the 
> 'source' property? label/comment and any other immediate explanatory 
> text? 

I can provide the schema. That's public. Attached.

Also attached is the schema we use for defining vocabularies.

(these and alot more will shortly be available/browsable from sw.nokia.com)

> Since referencing sources, provenence and suchlike is a trust centric
> application area, I am wondering whether we should have a 'Security 
> Considerations' <blink/> tag in our health warning for 
> reification. Maybe
> that's overkill, but I do worry that it is all too easy to 
> read properties
> such as 'source' as saying something like 'these uris were 
> used in this 
> rdf document'. I think the OWL machinery gives us a way of 
> showing that
> not to be workable...

We qualify resources, properties, terms, vocabularies, statements, etc.
according to confidentiality and filter responses accordingly. I don't
think that either reification or any information about reification
adds to the general security risks of uncontrolled access to triples.

Any machinery for constraining access to knowledge will work just as
well for reification knowledge. So I don't see a need for any special
verbage about security specific to reification. Though, of course,
it won't hurt either, so....  go ahead ;-)

Cheers,

Patrick