W3C home > Mailing lists > Public > www-rdf-comments@w3.org > October to December 2002

RE: [xml-dev] RDF for unstructured databases, RDF for axiomatic

From: pat hayes <phayes@ai.uwf.edu>
Date: Thu, 21 Nov 2002 11:07:38 -0600
Message-Id: <p05111b1bba02b8f4abb4@[]>
To: "Shelley Powers" <shelleyp@burningbird.net>
Cc: "Jonathan Borden" <jonathan@openhealth.org>, <xml-dev@lists.xml.org>, <www-rdf-comments@w3.org>

>I've also cc'd the RDF comments mailing list as this definitely reflects
>comments about current working drafts.

But please bear in mind that I am not here speaking for the WG; I 
havn't cleared these comments with them and other members might not 
agree; this is my take on things. So please if you (or anyone) cite 
any of this, cite Pat Hayes, not the RDF Core WG. And of course you 
can always read through the entire WG email archive and judge for 
yourself :-)

>>  What Ive tried to do in the RDF semantics doc is to at least mention
>>  everything, even if only to say 'we don't give this any meaning',
>>  which is the case eg for rdf:value. In some cases - reification and
>>  containers and now collections as well - we say that formally there
>>  is no (or very little) semantics, but that there is a kind of
>>  recommended-informal-interpretation, and  that 'semantic extensions'
>>  are allowed to impose meanings on these terms which conform to these
>>  outlines. This is a bit of a weaselly having-ones-cake-and-eating-it
>>  kind of position, I agree, but it seemed the best available
>>  compromise. The problem we had was that our charter is to clarify and
>>  make precise an existing language which had a flawed spec but was
>>  already in use, so we couldn't just write on a blank slate. In all
>>  these cases we *could* have given these things a 'tight' meaning, but
>>  there were options, and every option would have burned the fingers of
>>  some existing case users. So we didn't want to say that using other
>>  meanings violates the spec.. On the other hand, we do want them to be
>>  taken as strong recommendations for good future practice. So saying
>>  that extensions MAY assume these, is like saying: if your extension
>>  DOESNT assume something consistent with this, and it breaks when
>>  plugged into some RDF written by someone who DOES assume it, then its
>Pat, I understand the constraints that you all work under, but you're doing
>future consumers of RDF a deservice with this approach. This has
>re-introduced ambiguity. More than that, this approach makes it difficult to
>determine what is or is not 'compliant' RDF.

I don't agree that it has re-introduced ambiguity. To some extent RDF 
is inherently ambiguous: it cannot tie down its meaning to a single 
interpretation. In this it is in the same boat as all other 
assertional logics, including all the SW logics (DAML+OIL, OWL, etc) 
and things like KIF, CL, HOL, and all traditional logics. In this 
sense the spec is 'ambiguous', but to complain about that is howling 
at the moon.

There is a deeper issue as well. RDF is not a final product: it is 
intended to be the 'base' layer of a family of more expressive 
languages built on top of it. Some of these already exist - RDFS - or 
are being produced right now, eg OWL. We expect that there will be 
more. And several people expect that a wide range of other SW 
languages might get developed for a wide variety of purposes, but all 
in the same general framework and all conformant to RDF. This places 
RDF in a particularly tricky position regarding 'ambiguity' in this 
sense. For some purposes, it is probably best if RDF itself 
under-specifies some meanings, for now, as those meanings will be 
given a tighter meaning in later extensions built on top of RDF. 
Sometimes we expect that these tighter meanings will emerge from a 
process of consensus, which we do not want to pre-empt or pre-guess 
at this stage; sometimes, we think that alternatives might emerge, 
and in those cases we want RDF to be consistent with all the 
alternatives even when they are incompatible with each other. (The 
slightly odd treatment of rdfs:range in the current semantics is 
partly motivated by this way of thinking, for example. For extensions 
in the OWL style, a simpler definition of rdfs:range meaning would 
have been preferable; but there are other use cases for RDF, 
involving compatibility with strongly typed systems, where that 
simpler semantics would have been a problem. So we backed the RDF 
meaning off slightly to try to preserve future compatibility. )

>Your charter does not preclude you using the deprecation marker. From the
>HTML document:
>"A deprecated element or attribute is one that has been outdated by newer
>constructs. Deprecated elements are defined in the reference manual in
>appropriate locations, but are clearly marked as deprecated. Deprecated
>elements may become obsolete in future versions of HTML. User agents should
>continue to support deprecated elements for reasons of backward
>Definitions of elements and attributes clearly indicate which are

Right, I understand. But we (deliberately) aren't deprecating 
containers and reification in this sense, we are just clarifying 
their semantic boundaries and drawing them rather close to the chest, 
as it were. Similarly for containers.

Overall, this is an issue best brought up to the WG rather than to me 
personally. But its getting VERY close to final call, and I don't 
think we will want to make any large changes at this stage.

>>  >Processing -- each item in a sequence is related to every other
>>  item in this
>>  >way -- that is what is known in the computer world as 'processing'
>>  >information. As in, when you see this tool makers, this is how
>>  you process
>>  >it.
>>  Sure, but be careful about the phrase 'processing semantics', which
>>  is often used to convey the idea or claim that the *meaning* of the
>>  language is to be found in the processing done to the expressions of
>>  the language. This is true, or at least plausible, when its a
>>  programming language, particularly an interpreted programming
>>  language; but its not a good way to think about an
>>  assertional/descriptive language like RDF. Of course, RDF gets
>>  processed (hopefully) but the point is that in this case, the
>>  processing should follow the meaning, in the sense that it should
>>  constitute valid inferences, rather than defining the meaning.
>But Pat, there is a processing semantic attached to containers. That aspect
>of containers that represents a data structure -- a descriptive structure if
>you will -- a grouping of related items has no implied processing other than
>the relationship. However, when you give a Bag, Seq, and Alt type, you're
>attaching processing semantics to the construct. This is no different then
>attaching conditional processing semantics to 'if' in most programming

Sorry, I disagree, and think that your view is a misunderstanding of 
RDF. RDF really, really, really is not a programming language. It has 
nothing like a programming language's semantics: it doesn't assume 
that its domains are recursive or computable. It is more like a 
simple assertional logic, or a notation for a database, than it is 
like a programming language. So when you see rdf:Bag, that does *not* 
mean that RDF is constructing a bag, or defining a bag, or that an 
RDF processor is obliged to construct a bag-like datastructure which 
conforms to baggish behavior. (It MAY do that, but that goes beyond 
what the RDF actually says. On the other hand, if it does create such 
a datastructure, then it really would be a good idea to have it be 
treated baggishly rather than, say, listishly or settishly, if you 
see what I mean...)

What it actually means, by the way, is that some thing exists which 
is classified as an rdf:Bag and which has some other things in 
various 'positions' in it. That is all; and what being an rdf:Bag 
*really means* is not specified. But then what it *really means* to 
be in most RDFS classes is not specified, so what's new?

Now, if you were to say, then it's a damn shame that RDF uses names 
that strongly suggest programming language constructs, like 'bag' and 
'alt', then I would heartily agree. But those came with the package, 
and our charter required us not to make merely cosmetic changes.

>>  >
>>  >Actually, it has a lot of problems. It was created by a group of smart,
>>  >wonderful people who really care about making RDF work BUT who have a
>>  >difficult time understanding that not all of us have PhDs in
>>  linguistics and
>>  >mathematics. Or Philosophy.
>>  Well, I did try to write the semantics doc so that it didn't
>  > presuppose having technical qualifications in logic or philosophy,
>>  and explained its ideas as it goes along. If it was written for a
>>  technical/mathematical audience it would probably be about 1/3 the
>>  length and have hardly any English words in it. The Webont WG OWL
>>  semantics are written more in this style, you might find the contrast
>>  amusing.
>I'm actually not as concerned about the semantics document as I am the
>other. I think the biggest problem with the documents in difficulty
>understanding who your audience is.

Yeh, we have the same problem. :-)

>Is it the tools developers? The language
>semantician? The RDF end user? Rather than break across functional lines,
>perhaps the documents should have broken along audience lines. (Or did they?
>Is the RDF Primer the document for the end user?)
>>  >They add references to containers in the primer and the syntax,
>>  but in the
>>  >semantics document, add this statement basically forcing interpretation
>>  >about 'containers' back on the user.
>>  Have you read the newest draft? It tries to give a better exposition
>>  of RDF container. The key point is that RDF *describes* containers
>>  rather than *constructing* them. Then the rather sparse semantics
>  > makes more sense, I think: its not saying that the containers
>>  themselves are 'thin' or ambiguous; its just that RDF doesn't say a
>>  whole lot about them.
>Enough to be possibly damange the credibility of the release.

If you think of RDF containers as RDF-defined datastructures, then 
your comment would be justified; but that is not the right way to 
think about them.

>>  >In this case, they definitely
>>  >re-introduced ambiguity. Why? Because a lot of them don't like
>>  containers,
>>  >they wanted to get rid of containers, they think containers are
>>  redundant.
>>  No, not at all. The problems run deeper. The real problem is that if
>>  containers are unordered (like rdf:bag) and you use an ordered set of
>>  selection functions on them, then you are kind of imposing an order
>>  on what is conceptually an unordered thing. So your description in a
>>  sense says *too much* about it. So if we allow RDF to make any formal
>>  entailments about bags, they are almost all going to be wrong, in
>>  fact, so we had to block them. For example suppose you say that A is
>>  a bag and its first item is X and its second item is Y. If you allow
>>  RDF to permute the items, then you can infer that Y is the first
>>  item. But now *both* X and Y are the first item...
>>  There are other problems, notably with there being no way to say that
>>  a container is 'closed', ie has no more elements.
>And that's why I don't like containers in this type of model.

What do you mean by 'type of model'? (I think we may agree, if you 
mean what I think you mean. But Im in the minority in the WG on that 

>>  >Worse, containers add processing semantics to what is a data
>>  model. I happen
>>  >to agree with them -- containers are redundant. They were, at one point,
>>  >actually pulled from RDF. Or at least there was a WG note for this at one
>>  >point.
>>  Yes, that might have been one option. Another would have been to
>>  redesign the containers from the ground up; we could have done a much
>>  more elegant and formally tight version. But the old container
>>  vocabulary would then be deprecated, and we felt this was needlessly
>>  drastic, particularly as we were adding collections to overcome many
>>  of the problems. Making something retrospectively illegal is not an
>>  action to be taken lightly.
>As stated previously, deprecation is good and doesn't necessarily hurt your
>existing tool and RDF users. W3C has used deprecation with HTML, and it has
>a much wider user base. Deprecation would not have violated your charter.
>As for not doing it lightly -- leaving in vaguely defined semantic
>constructs strikes me as a bit more serious. Wouldn't you think?

Well, no; because in this sense of 'vaguely', *all* assertional 
semantics are 'vague'. One only gets non-vagueness in this sense when 
describing domains which satisfy the recursion theorems, which 
guarantee that recursively described domains are unique. Programming 
languages do that. Most of the worlds that RDF will be used to 
describe (worlds containing things like people, wines, works of art, 
aircraft) are not recursive (computable) and cannot be tied down 

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam
Received on Thursday, 21 November 2002 12:07:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:01 UTC