Re: comment on proposed policies for vocabularies

From: "Miles, AJ \(Alistair\)" <A.J.Miles@rl.ac.uk>
Subject: RE: comment on proposed policies for vocabularies
Date: Tue, 22 Nov 2005 12:02:48 -0000

> Hi Peter,
> 
> Thanks alot for this feedback, much appreciated.
> 
> > I just read http://isegserv.itd.rl.ac.uk/VM/http-examples/ 
> > and I have a number
> > of concerns.
> 
> Note revised draft at:
> 
> http://www.w3.org/2001/sw/BestPractices/VM/http-examples/2005-11-18/
> 
> ... with revised language for the 'requirements'.
> 
> > These concerns mainly center around whether it is generally 
> > possible [that], "[f]or
> > each HTTP URI denoting an RDFS/OWL class, property or 
> > individual" there is a
> > general notion of "a set of RDF statements constituting the 
> > definitive RDF
> > description of that class, property or individual".
> > 
> > First, some simple concerns.  Shouldn't it be an RDFS 
> > description, at least?
> > How can one distinguish between (non-OWL DL) RDFS classes, 
> > properties, and
> > individuals to determine just what to return?
> > 
> > Second, an OWL class, property, or individual should have an 
> > OWL description
> > instead of an RDF(S) description.  (Unless, of course, you 
> > really mean to get a
> > projection of an OWL description onto RDF(S).) 
> 
> I think this is a question of finding the right language.

Yes, but how?  What mechanism is there to determine which is the right language.

> By 'RDF description' of some thing I meant: a set of RDF statements 'about'
> (i.e. 'describing') that thing.  This was not meant to exclude RDF statements
> using RDFS properties/classes, or the RDF projection of an 'OWL description'.

I don't know what "the RDF projection of an 'OWL description'" would be.

> Note also that this is not in my mind necessarily restricted to only RDF
> statements for which the thing in question is in the subject position, but
> more a set of statements for which the thing in question is the focus. 
> 
> Any suggestion for how we could improve language here?

The problem is not just improving the wording; the problem has to do with
determining which language will be used.  Consider that some
applications/agents will not be able to correctly process information that uses
OWL semantics; other agents will depend on OWL semantics.  How, just given an
HTTP URI, can an application say what it wants?  How, just given an HTTP URI,
can a service provide appropriate information?

> > Third, there could be several "definitive" descriptions.  I 
> > might have one; you
> > might have one; George W. Bush might have one.  What makes my or your
> > description more definitive than the one used by George W. 
> > Bush?  I don't see
> > how this potential multiplicity can be resolved.
> 
> I think this is also a question of finding the right language. 

No, this has nothing to do with finding the right language.  The Web, and the
Semantic Web, is very decentralized.  Why should I be forced to subscribe to
a centralized meaning for every URI that I use?  

> In
> conversation at ISWC2005 I remember you saying that it is reasonable for
> there to be a 'core' description for a class or property ... can you expand
> on this notion?  

Sure, it is to be expected that almost all uses of almost all identifiers
(including HTTP URIs) share a core meaning.  My view, however, is that turning
this strong expectation into a requirement is not a good idea.

> I had always assumed that[] to be able to access this 'core' description of a
> class/property by dereferencing the URI of that class/property was a (the?)
> fundamental principle of the architecture of the semantic web. TimBL seemed
> to reiterate that quite firmly in his keynote at ISWC2005. Do you agree with
> this?  

No I do not agree.  

> > Fourth, is there any way to limit what is in the "definitive" 
> > description?
> > To take an extreme viewpoint, *every* use of dc:author would 
> > be part of its
> > "definitive" description.
> 
> Again, if you could expand on a notion of a 'core' description, I think that
> would be helpful here. 

I don't have an operational one.  However, I'm not the one advocating that
there be a "definitive" or "core" or anything other kind of description for
identifiers, so I'm not in the position of needing one.  That is your job, or,
at least, the job of those who want to propose the requirement.

> > I have similar concerns with "... the most relevant item of 
> > human-readable HTML
> > content documentation for that class, property or 
> > individual".  This is making
> > a *very* strong statement that relevance can be determined 
> > for each particular
> > request.  How can a piece of software know what I consider to 
> > be most relevant?
> 
> This was a purely pragmatic requirement. I.e. if I 'go' to the URI of a
> property using my web browser, it's usually more convenient if I end up
> looking at a description of that property, rather than the
> vocabulary/ontology as a whole or something else. This might mean scanning to
> the most relevant fragment of an html doc, or going to the right page in a
> linked set of docs. 

But the problem is not finding a piece of text in a known document, the problem
that you have set yourself is finding the "... the most relevant item of
human-readable HTML content documentation for that class, property or
individual" whereever that might be.  This "most relevant item" might be
elsewhere; it might be different for different uses; it might not even be
accessible on the public web.

> > Note that I am *not* saying that there is nothing that can or 
> > should be done
> > along these lines.  It is just that the desiderata in the 
> > document are, in my
> > opinion, impossible to satisfy.
> 
> What do you think the desiderata should be? Are we generally barking up the
> right tree, or have we got something fundamentally wrong? Is it a question of
> finding the right language? If so, any suggestions? 

I do think that you are doing something fundamentally wrong in setting such
high standards.

I believe that it would be much better to strive for something along the lines
of:

For any HTTP URI used as an identifier in the Semantic Web
1/ there should be a way of finding a machine-processable document that
   provides some information about the formal meaning of that identifier;
   and
2/ there should be a way of finding a human-readable document that 
   provides some information about the intended meaning of that identifier.

This is, of course, only the start of a mechanism.  Some of the rest of the
mechanism can be partly supported by existing web standards, such as content
negotiation for getting the correct version of the machine-processable document
and intra-document tags for finding a place in a human-readable document.  Both
could use some help from extensions:  for the former a separate MIME-type for
OWL would be of use; for the latter tagging multiple portions of a document
would be better than just tagging a single point in a document.

> Cheers,
> 
> Alistair.

peter

PS:  I note that the new version of the document says something about not
introducing inconsistency.  I have no idea how this would actually work, and I
have doubts that it can be done at all.

Received on Tuesday, 22 November 2005 12:50:10 UTC