W3C home > Mailing lists > Public > www-rdf-logic@w3.org > November 2000

RE: What is an Ontology? [was: daml-ont]

From: McBride, Brian <bwm@hplb.hpl.hp.com>
Date: Wed, 1 Nov 2000 19:13:09 -0000
Message-ID: <5E13A1874524D411A876006008CD059F23946F@0-mail-1.hpl.hp.com>
To: "'Dan Connolly'" <connolly@w3.org>
Cc: www-rdf-logic@w3.org
> There are (at least) two senses of the term 'document'
> in web literature:
> 
> "document 
>       1.aka resource; aka Node; See also: visit 
>       2.aka page, frame, card 
>       3.a bit of data 
>             in [SGML86] 
>             in [HTML95], 3.2, 4.0 "
> 	-- http://www.w3.org/Architecture/Terms#document
> 
> In the comment property on Ontology, I was using
> document in the first sense, i.e. an "abstract
> entity" that may have many possible representations,
> rather than in sense 3, a particular byte-sequence.
> (hmm... "visit" really belong with sense 2,
> i.e. a compound document with embedded images
> and such.)

I understand what you mean now.  As an aside, I noticed
that the glossary entry for resource has no aka document
- suggestive that a document is a resource, but not
all resources are documents.


[snip]

> 
> My model is based on a sort of modal-logic
> approach to integrating RDF statements into the
> real world of communication protocols; consider
> a property
> 	entails: Message -> Statement	
> 	for entails(m, s) read: the message m entails
> 	the statement s
> 
> and
> 	about: Message -> Resource
> 	for about(m, r) read: message m is about r;
> 	e.g. when you fetch http://example.org/page1,
> 	the HTTP GET message you send, and its reply,
> 	are about http://example.org/page1
> 
> These allow me to state the axioms I have in
> mind for daml:imports ; namely:
> 
> 	entails(?xReply, `daml:imports(?x, ?y)')
> 	/\ about(?xReply, ?x)
> 	/\ about(?yReply, ?y)
> 	/\ entails(?yReply, ?aStatement)
> 	=> entails(?xReply, ?aStatement)

Hmmm... so if that document contained the following:

  <Ontology about="http://foobar/onto">
    <imports resource="http://bar/onto"/>
  </Ontology>

then that axiom will not fire because the URI that the
client used to fetch the resource does not match the
absolute URI given in the about attribute.  You won't
believe an import statement unless it was fetched using
the same URI as in the about!

So if I created an ontology, put absolute URI's on
everything, but stored it at a different network address,
e.g. on the ontologies'r'us.com repository, you wouldn't
believe the import statements in it.

If the ontology is fetched via some other URI - lets say
for some reason the client fetches the page using 
ftp://example.org/page1.  Should the semantics of an
ontology change because a different protocol was used to
access it?


[snip]

> 
> > [I am in general supportive of Sergey's stylistic suggestion
> >  that in general, URI's in about attribute values should be
> >  absolute - it is rather irritating to cut and paste a self
> >  contained chunk of RDF and find the semantics have changed.
> >  Also, if a mirror service stores an exact copy of an RDF
> >  document, to have the copy have different semantics to
> >  the original seems unhelpful.]
> 
> It's entirely feasible to mirror some content without
> replublishing it at a different address. For example,
> the W3C web site is mirrored at a dozen or so
> locations in IP-space (and physical space) but all
> the mirrors are at the same address in Web space:
> http://www.w3.org/ .

Yes it can be done.  But is it reasonable or necessary
to prohibit it being done in other ways?  Principle
of minimal constraint and all that.

> 
> Republishing stuff at a different address is
> another matter entirely, and folks shouldn't
> get the impression that it can be done without
> complications in the general case: relative
> URI references are a small technical matter
> compared to access control, metadata
> about copyright/licensing, digital signatures,
> etc.
> 
> Style is a matter of taste and experience.
> My experience leads me to favor relative URI
> references.


Sure.  I've had my 2c.

Brian
Received on Wednesday, 1 November 2000 14:13:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:32 UTC