Re: Proposed draft RDF Graph vocabulary

>On Mar 15, 2004, at 15:12, ext Jeremy Carroll wrote:
>
>>
>>>Suggestion: shall we use 'rdfg:' for "RDF Graph" rather than the more
>>>cryptic/arbitrary 'rdfx:'?
>>
>>I'll use a latex macro, and then later, in a flush of ambition, we can
>>change it to rdf2:!
>
>Er, ah, ahem... remember what I said about "targets"... ;-)
>
>>
>>>
>>>--
>>>
>>>     rdfg:Graph
>>>        a rdfs:Class ;
>>>        rdfs:comment "An RDF graph (with intensional semantics)." .
>>>
>>>     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. 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.

>
>>
>>>
>>>     rdfg:Signature
>>>        a rdfs:Class ;
>>>        rdfs:comment "A signature used to authenticate a graph." .
>>>
>>>Again, we don't say more about exactly what an rdfg:Signature is, only
>>>that it has a particular purpose in authentication of the statements
>>>and instances should be suitable for that purpose.
>>
>>I was thinking more along the lines of a property rdfg:signature, and
>>possibly rdfg:signatureType (with some well-known values). I was also
>>thinking of putting references into: my earlier work on Sigs; a related
>>paper from HP colleagues; DanBri's point about foaf signatures. Maybe these
>>signaturetypes should be subclasses of rdfg:Signature?
>
>I think subclassing rdfg:Signature is cleaner than having the extra
>property.
>
>>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:)

>
>I don't think we need to be prescriptive about the structure of
>signatures. What counts is their function, which is to authenticate
>a particular graph for a particular authority. Beyond that, let
>the industry decide whichever structure works best, or even happily
>live with several alternatives.
>
>>
>>>
>>>     rdfg:sameAs
>>>        a rdf:Property ;
>>>        rdfs:comment  "The subject and object graphs are equivalent as
>>>defined by RDF Concepts." ;
>>>        rdfs:domain rdfg:Graph ;
>>>        rdfs:range rdfg:Graph .
>>>
>>>I think that some localname recognition with OWL would be useful here,
>>>even
>>>if the semantics is not identical. But something like rdfg:equivalentTo
>>>would
>>>also be OK.
>>rdfg:equivalentGraph is my pref for this one - it mirrors the OWL names
>>better.
>
>OK. Let's go with rdfg:equivalentGraph.
>
>>
>>>
>>>     rdfg:subsumes
>>>        a rdf:Property ;
>>>        rdfs:comment "The object graph is equivalent to a subset of the
>>>subject graph." ;
>>>        rdfs:domain rdfg:Graph ;
>>>        rdfs:range rdfg:Graph ;
>>>        owl:inverseProperty rdfg:subsumedBy .
>>>
>>>     rdfg:subsumedBy
>>>        a rdf:Property ;
>>>        rdfs:comment "The subject graph is equivalent to a subset of the
>>>object graph." ;
>>>        rdfs:domain rdfg:Graph ;
>>>        rdfs:range rdfg:Graph ;
>>>        owl:inverseProperty rdfg:subsumes .
>>>
>>>I expanded rdfx:subGraphOf into a pair of inverse properties, allowing
>>>one to
>>>relate two perfectly intersecting graphs from either perspective.
>>>
>>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?).

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.

>>>     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.

I'll write the semantic equations so that the truth-conditions come 
out OK, but I have to be able to refer to this real stuff (like, 
I(<object of an assertedBy triple>)=the actual agent doing the 
asserting of this actual graph ). I need input from y'all on what to 
say at places like this.

>
>That's just how I tried to capture those bits and the
>key distinctions between them.
>
>I'm certainly open to other alternatives.
>
>>
>>>
>>>     rdfg:assertedBy
>>>        a rdf:Property ;
>>>        rdfs:subPropertyOf rdfg:authority ;
>>>        rdfs:comment "The object is the asserting authority of the
>>>subject graph." ;
>>>        rdfs:domain rdfg:Graph ;
>>>        rdfs:range rdfg:Authority .
>>>
>>>Note that rdfg:assertedBy is a subproperty of rdfg:authority, so one can
>>>both associate the authority and explicitly assert with a single
>>>statement.
>>>Those who don't care about quoting or the distinction between authority
>>>and assertion can happily just use this property and ignore
>>>rdfg:assertion
>>>and the distinction it provides for...
>>>
>>
>>I think we need to go more fine-grain here, more later.
>>But I agree with you about following rdf-mt in its used of
>>assert(ion)(al)(ed) etc.
>>
>>>     rdfg:signature
>>>        a rdf:Property ;
>>>        rdfs:comment "The object is the signature to be used to
>>>authenticate the subject graph." ;
>>>        rdfs:domain rdfg:Graph ;
>>>        rdfs:range rdfg:Signature .
>>>
>>>Again, we don't mandate what the signature is (there may be multiple
>>>alternatives
>>>in use) only provide the means to associate a signature with the
>>>particular graph.
>>>
>>
>>Oh yes that works better ...
>>
>>>--
>>>
>>>The bootstrapping interpretation/test looks specifically for the
>>>properties rdfg:assertedBy and (optionally) rdfg:signature where the
>>>subject of those "literal" statements is the same URIref as that
>>>naming the graph in which they occur.
>>
>>I think we should avoid mandating a particular bootstrapping phase, more
>>indicate a possible bootstrapping phase. The bootstrapping is done by an SW
>>agent, and its policies should be decided by its user rather than
>>architecturally. I believe we have agreement on that.
>
>Yes. It's perhaps a misnomer to use the term 'phase', so I'll back
>up a bit and say that there is simply a bootstrapping interpretation/test
>which is performed on a specific graph per its "literal" statements
>(examining the abstract graph syntax).
>
>This can be done prior to syndication to a knowledge base (where
>only triples are stored) or at any time in a knowledge base which
>preserves graph membership of statements -- since one can then always
>example a graph in isolation.
>
>In fact, this "bootstrapping interpretation" may even be an integral
>part of run-time application of trust policies by an agent using
>a knowlege base that provides full support for names graphs and
>graph qualified queries.
>
>>
>>>
>>>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.

>
>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.

>
>Most of the interpretation/utility of those statements are well
>within the scope of the RDF and OWL MTs, which is one good reason
>why the vocabulary approach is preferable to the XML syntax approach.

I agree, modulo the above.

Pat

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


-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Monday, 15 March 2004 20:31:53 UTC