Re: Proposed draft RDF Graph vocabulary

On Mar 16, 2004, at 03:31, ext Pat Hayes wrote:

>>>>     rdfg:Authority
>>>>        a rdfs:Class ;
>>>>        rdfs:comment "An authority, or origin, of a graph." .
>>>>
>>>> We don't say more about what an rdfg:Authority actually is. We only
>>>> (vaguely)
>>>> define that such a class of entities exist which have a particular 
>>>> role
>>>> with regards to trust.
>>>
>>> "For example, a person or company."
>>
>> Sounds reasonable.
>
> BUt we need to be able to refer to the authority associated with a 
> particular graph, in the MT.

See the rdfg:authority and rdfg:assertedBy properties, which associate
a member of the class rdfg:Authority with a graph.

> formally we can say that the interpretation is relative to an 
> 'authority mapping' which interprets URIs denoting authorities to 
> actual authorities, or some such trick. But I need real authorities in 
> the MT somewhere.

The 'real' authorities would be whatever are denoted by the URIs. So 
given

    some:graph rdfg:authority some:authority .

then whatever is denoted by some:authority is the actual authority of 
the
graph denoted by some:graph.

Right?
>

>>> Isn't a signature at the end of the day a byte-sequence, so having a
>>> property
>>> rdfg:signatureBytes with domain rdfg:Signature and range
>>> xsd:hexEncodedByteSequence (I need to look up the correct name).
>>
>> I was actually considering defining rdfg:Signature as an 
>> rdfs:Datatype,
>> but decided that would just distract too many folks...
>>
>> But particular subtypes of rdfg:Signature could certainly be modeled
>> as datatypes.
>>
>> It could, though, be modelled as e.g. a structured object denoted
>> by a bnode with various characteristics defined by properties.
>
> It can still be in the datatype class, though. (I'm siding with Jeremy 
> here, but I think I agree with Patrick:)

Actually, I think we're all in agreement here as to the optimal nature
of signature values in practice -- I simply chose to make the vocabulary
agnostic for the sake of genericity, since it is not critical to the
key points of our presentation.

It doesn't matter really how the signature is expressed, only that
it serves it function. The class rdfg:Signature only aims to reflect
that function, not any particular form. Particular forms can be
mandated for instances of particular subclasses of rdfg:Signature,
including datatypes.

>>> Save space and delete one -
>>
>> It seems to me that choosing only one leaves a gap in the
>> expressivity -- like having ex:wife but not ex:husband, etc.
>> It's mostly an issue of esthetics for me.
>
> For the record, OWL faced similar choices and decided to go with one 
> in each case as a design decision. Users are free to define the 
> inverses if they want them.
>
>>
>>> I slightly prefer subGraphOf to subsumes - it is
>>> clearer what one is talking about.
>>
>> I agree. But I didn't really like rdfg:superGraphOf ;-)
>>
>> If we go with only one such property, then we can use rdfg:subGraphOf.
>> If we stick with both, then the rdfg:subsumes/subsumedBy seems more
>> balanced.
>>
>> Pat, Chris, any preferences.
>
> OK, I'm lost. I have no idea what you guys are trying to do here, or 
> what the point of all this vocabulary is supposed to be.
>
> Take subgraph. Whether or not graph A is a subgraph of graph B is just 
> a fact: it either is or it isn't, and you can check the actual graphs 
> to find out.  Now, what exactly is added by being able to say this in 
> RDF? Suppose that A is in fact not a subgraph of B but you assert
>
> A rdfg:subGraphOf B .
>
> This is false.  Should it count as an inconsistency, or is it just 
> plain false? Is it an inconsistency relative to a graph naming (like a 
> D-inconsistency)? That would make a kind of sense...

>
> Similarly signatures. Suppose a graph lies about its real signature: 
> it is signed by ex:joe, in fact, but it asserts that it is signed by 
> ex:bill. Is this inconsistent? If so, the semantics has to somehow 
> refer to the actual signature. (How?). If not, the semantics hasn't 
> got to do anything, and all this vocabulary is just user vocabulary 
> (so why are we worrying about it?).

I don't think we're introducing any new problems here.

Claims/statements about graphs or authorities or signatures are just
claims, and they may be false, or lead to disagreements or 
contradictions,
but testing of those claims or resolution of disagreements or 
contradictions
will always be an extra-RDF activity.

To test if A rdfg:subGraphOf B is true or not requires comparing both
graphs -- which is (I believe) not defined by the RDF MT as an explicit
test by which one determines consistency.

To test if ex:bill is or is not the valid authority for an 
asserted/published
graph will involve PKI machinery or the like, which clearly is an 
extra-RDF
process.

To test if ex:sky ex:is ex:blue will require some extra-RDF 
determination.

Again, I fail to see how we are introducing any new problems.

> OK, that is all just semantics. But what is the *utility* of being 
> able to say this stuff in RDF? No amount of RDF vocabulary is going to 
> actually get any asserting done or provide any signature security all 
> by itself.  This seems to me to be like deciding how to talk about 
> locks and keys, but not having any actual locks and keys.

We are allowing folks to make claims in RDF about those locks and keys 
-- and
those claims are then interpreted per the RDF MT, even if the testing 
of those
claims require extra-RDF machinery (as outlined above).

It is useful to be able to reason about those claims of authority, 
signatures,
trust, etc. perhaps prior to employing any extra-RDF tests -- e.g. to 
determine
whether we even care to apply any tests, or which test might be the best
to try first.

It's putting as much of the trust/authentication machinery into RDF 
space
so that we can use as much of the RDF machinery as we can, which also
reduces the amount of additional extra-RDF machinery that is needed to
achieve a complete solution.

Some of this is put into RDF because it's useful to do RDF-like things
to it. Some of this is put into RDF simply to avoid having to put it
elsewhere (e.g. in the XML syntax), even if one is likely never to
do RDF-like things with it.

>
>>>>     rdfg:authority
>>>>        a rdf:Property ;
>>>>        rdfs:comment "The object is the authority, or origin, of the
>>>> subject graph." ;
>>>>        rdfs:domain rdfg:Graph ;
>>>>        rdfs:range rdfg:Authority .
>>>>
>>>> This property simply associates an authority with a particular 
>>>> graph.
>>>> It does
>>>> not assert anything. This can be used to clearly indicate the 
>>>> origin of
>>>> the
>>>> graph without that origin/entity making any actual claims (e.g. the 
>>>> end
>>>> result being akin to quoting, if not otherwise asserted by that
>>>> authority
>>>> elsewhere).
>>>
>>> Not yet convinced here.
>>
>> I would like for there to be a way to publish a graph, and even
>> sign it with an explicit authority, yet not actually assert the
>> graph
>
> I agree. Publication and (real, secure) assertion ought to be 
> orthogonal.
>
>>  -- or perhaps leave it open to conditional assertion using
>> a special vocabulary, per my recent "ErrorState" example.
>>
>> And if you don't have an authority specified, you have no idea
>> with/for whom to authenticate the signature.
>>
>> Our three pieces to the puzzle are:
>>
>> 1. Authority
>> 2. Signature
>> 3. Assertiveness
>>
>> The first is provided by rdfq:authority, either directly
>> or via rdfg:assertedBy per the rdfs:subPropertyOf closure.
>>
>> The second is provided by rdfq:signature.
>>
>> The third is IMO optional, and provided by rdfq:assertedBy.
>
> None of these can be PROVIDED by any RDF. RDF can only DESCRIBE 
> things. I agree about the distinctions, but if we are going to 
> actually use RDF to DO this stuff, then we need to semantically anchor 
> the special vocabulary in something real, like real signatures, real 
> agents who can assert things, and so on.

Let me rephrase. The statement (potential claim) about assertiveness
is provided by the rdfq:assertedBy property.

Whether the graph is or is not considered as actually asserted
by some agent depends on that special "bootstrapping interpretation"
which is, agreed, outside the scope of the RDF MT.

>>>
>>>>
>>>> Statements using any of the above vocabulary are fully valid and
>>>> compatible with both the RDF and OWL MTs irrespective of the
>>>> special bootstrapping interpretation/test necessary for 
>>>> determination
>>>> of (terminal) assertion and authentication.
>>>>
>>>
>>> Yes bootstrapping is not very special.
>>
>> It's just a means to terminate the trust/assertion chains expressed
>> in the various graphs since the RDF MT can't do that for us.
>
> I think that only a suitable MT can possibly do that for you. But it 
> has to be able to talk about the real stuff.

For any graph where

    ?graph ( ?graph rdfg:assertedBy ?authority . )

then the graph denoted by ?graph is to be taken as asserted,
by the authority denoted by ?authority.

That, in a nutshell, is the bootstrapping interpretation for
assertiveness.

It's extra-RDF in that, the RDF MT doesn't view the above triple
as a triple if the graph is not asserted -- but the triple is
what is asserting the graph. Hence the appropriateness of the
term "bootstrapping".

The special MT needs to capture how the graph "asserts itself
by its bootstraps".

This is distinct from third-party assertion where one has
a graph that is deemed (by whatever means) to already be
asserted, and which has a statement which asserts another
graph.

The bootstrapping assertion of one graph an then result
in the chain-assertion of several other graphs which
otherwise would never be taken as asserted due to the
absence of any bootstrapping statements.

Authentication is similar:

For any graph where

    ?graph ( ?graph rdfg:authority ?authority .
             ?graph rdfg:signature ?signature . )

(where rdfg:authority may be inferred from rdfg:assertedBy)

then the graph denoted by ?graph is to be taken as authentic,
if the specified signature denoted by ?signature is valid
for the authority denoted by ?authority, per some extra-RDF
validation test.

Again, this requires an extra-RDF interpretation since the graph
in question may not be otherwise taken to be asserted, per the RDF MT,
but still needs to be interpreted in terms of the relevant triples in
order to obtain and test the signature against the authority.

In all cases, these special interpretations are bound to specific
predicates, so hopefully that helps capture what's needed in the MT.

>
>>
>> We may even wish to find some other term than 'bootstrapping'
>> (perhaps 'anchoring') to get further away from the phase/process
>> connotations that bootstrapping drags into the mix...
>
> Yes, I like anchoring. Or, another term used for this is 'grounding'. 
> The meanings of this stuff have to be grounded in the real world of 
> agency, assertion and trust somehow.

I'm fine with you choosing some other term(s), so long as the
end result is the same.

I use the term bootstrapping because I'm a software engineer and
that is what appears to be happening -- particularly in the case
of assertion -- but 'anchoring' or 'grounding' may very
well be more appropriate.

Patrick

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Tuesday, 16 March 2004 03:29:11 UTC