Re: Hidden triples and self-description

On Sat, Sep 13, 2003 at 01:51:46PM -0400, Jonathan Borden wrote:
> Mark Baker wrote:
> 
> >First, let me define a "hidden triple" to be a triple which is not
> >extractable from a document by an RDF processor.  A trivial example is
> >this; 
> >
> >:myProperty rdfs:domain :myClass .
> >:some-object :myProperty :some-other-object .
> >
> >where one hidden triple (are there more?) would be;
> >
> >:some-object rdf:type :myClass .
> >  
> >
> That would be an _entailment_ licensed by either the RDF or OWL model 
> theories see: http://www.w3.org/TR/owl-test/#testEntailment

Ah, thanks.  I'd heard the word before, but never had a reason to learn
what it meant.

> >As a REST fan, I'm always on the lookout for things that appear
> >non-RESTful, and I believe this may be one, as that triple is not
> >visible to either intermediaries nor the recipient, unless they also
> >know RDF Schema (this isn't RDF Schema specific, of course).
> >  
> >
> Well yes I suppose but similarly an HTML document cannot be displayed by 
> an intermediary or agent that doesn't know HTML.

I think that's different.  All parties may know RDF, but those that know
the rules of entailment will extract additional triples from the same
message.  Hence my comment about media types; if it is the intent of the
sender to communicate this additional triple, then using the RDF media
type isn't sufficient.

> Indeed the RDF and OWL 
> model theories are published in well known places, so isn't it sort of 
> obvious that if you are going to use the RDF or OWL model theories to 
> derive entailments, that you'd have to know the rules of entailment?

I don't know.  But I see that there's some disagreement over this in
the community, e.g. (at least this appears to be talking about the
same thing)

http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Oct/0090.html

> >Another would be if it was the intent of the sender to not attempt
> >to communicate the hidden triple.  This, I'm quite fuzzy about; what
> >does it mean that a sender wants to communicate, versus not, a hidden
> >triple?  Does it suffice to say that no sender should ever intend to
> >send a hidden triple?
> >  
> >
> Well you can always send RDF as application/xml in which case you aren't 
> defining any triples at all... just sending RDF/XML _as XML_. In any 
> case the idea is that if you use rdfs:domain or rdfs:range, the 
> _meaning_ of these predicates is derived from their corresponding URIs 
> e.g. look at the RDFS namespace document for rdf:ID="domain" ... this is 
> a current TAG issue "meaning of RDF predicates"

I did actually look there to see what it said while investigating this.
I was half-expecting to see a rule there for infering that triple.

> I don't have a REST issue with this. I would like some specs to make the 
> connection between the meaning of a predicate and its URI more explicit 
> i.e. provide a rule such that the meaning of an RDF predicate (such as 
> rdfs:domain) is determined by dereferencing its URIref using 
> application/rdf+xml and processing the definition according to what is 
> found ... if it points to a triple whose subject is "rdfs:Class" or 
> "rdf:Property" then process according to the RDF(S) model theory, and if 
> it points to "owl:Class" or "owl:ObjectProperty" then according to the 
> OWL model theory... there remain a few issues but that's how I see it. 
> At some point when we are dealing with the meaning of media type 
> specific messages we need to delegate to the media type registration. 

Yes, exactly.  That's part of what I had in mind; dereferencing media
types (which practically requires them being URIs, but I think that's
doable too).

> The Semantic Web is all about doing this in an automatic fashion (e.g. 
> each media type would (ideally) have its own model theory ... and they 
> might all fall within the L-base framework).

"L-base"?  Ah, found it.  Uh oh, more reading ...

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Saturday, 13 September 2003 23:27:30 UTC