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

<snip>

>
> 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. )
>

Pat, you're the ultimate researcher, and I'm the ultimate applied engineer.
As such we have to discover each other's language. When you say that RDF is
not a final product and that it is the base of more expressive languaged, do
you see RDF/XML as one of the more 'expressive' languages?


> >
> >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
> >compatibility.
> >
> >Definitions of elements and attributes clearly indicate which are
> >deprecated."
>
> 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.
>

Personally, I don't want to see anything hold this delivery up. But when I
write about RDF, I have to understand who RDF is targeted to. I'm writing a
book, "Practical RDF". The longer this discussion continues, the more I
think that title is a heavily ironic oxymoron.

I see RDF as comparable to the relational model, and RDF/XML as a generic
RDBMS. You can build on an RDBMS and make more sophisticated products such
as SAP, PeopleSoft, and Oracle Financials (which I would equate to your
ontologies), but you can also use the 'RDBMS' directly for your
applications.

Forgive me trying to find a common analogy, but this is again trying to
discover a shared language. If this viewpoint is wrong, then I have made a
serious disconnect with the RDF documents at some point.

> >
> ><snip>
> >
> >>
> >>  >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
> >language.
>
> 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...)
>

Then why does the RDF documentation mention Bag, Seq, and Alt? Why
differentiate between types of container? What possible reason and _use_
would this be?

> 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.
>
> >
> ><snip>
> >
> >>  >
> >>  >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.
> >>
> >

Didn't Jonathan put gun to his head and go 'bang!' at about this point?

> >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
> point.)
>
> >
> >>  >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
> uniquely.
>

I'll drop these questions back and forth before someone comes along and says
they're outside of the scope of the mailing list. I am concerned, though,
about who is the target audience for RDF (documents, RDF/XML, and all).
However, I must be too dense because every time we cycle through one of
these question/response, I feel less and less that RDF will ever have a
directly 'practical' use.

However, as I said earlier, Pat, yours and my experiential differences are
vastly different. That would account for much confusion.

Shelley

Received on Thursday, 21 November 2002 13:24:46 UTC