- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Mon, 15 Mar 2004 15:49:07 +0200
- To: "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com>
- Cc: <phayes@ihmc.us>, <www-archive@w3.org>, <chris@bizer.de>
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. > >> >> 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. 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. > 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. > >> 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 -- 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. 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. 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... 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. Patrick -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Monday, 15 March 2004 09:10:07 UTC