RE: RDF Semantics: Interpretations and Modelling

My humble opinion is that RDF (that is, the W3C recommendation) shouldn't
define any syntax without a formal definition of semantics as well. If,
e.g., bags are not to be included to the RDF Semantics, then the
associated syntax should be informative only. Let the blank nodes and
properties (defined elsewhere, perhaps in a OWL kind of working group) to
do the trick.

The core should be as simple and clear as possible. (I guess it's too late
to get rid of all the alternative ways of serialising RDF in XML :-) )

.. *blink* ..

Reading the bag discussion I begun to wonder if the (restricted) idea of
"assertions" is appropriate in the context of RDF in the first place.

In several contexts, RDF is described as an "assertional language"
asserting "propositions". In practice, RDF Semantics begins with this very
phrase. This is fine if we consider only simple entailments.

However, given the possibility of making semantic extensions of RDF,
emphasising the property "assertional" seems unnecessary (and perhaps
misleading as well): introducing new semantic conditions and combining
different vocabulary entailments (the useful scenario) probably leads into
RDF graphs which could be described as hybrid networks (when associated
the appropriate processing rules).

To ground this discussion, a nice, easily accessible classification about
various "kinds" of semantic networks can be found, e.g., at

	[1] http://www.jfsowa.com/pubs/semnet.htm

(Note: I'm NOT assuming the people reading my mail don't know the terms, I
simply give the above address so that there would be something at hand to
ground the terms to.)

Following the concepts in [1], I believe that most RDF applications would
treat RDF graphs as hybrid networks for doing all sorts of things. That's
for RDF is for, a framework?

If there's something that prevents, e.g., a group of mathematicians
defining an RDF extension suitable for doing ordinary first-order logic
(*), that design choice of RDF should be spelled out with BIG letters in
the cover page of RDF specs. As I see it, I can always choose not to use
[or invent a pathological model for that part] a specific, too restricting
vocabulary if I don't want to. Or is this prohibited somewhere in RDF
specs?

I understand that the nature of "assertional propositions" states that
there's no superior authority who can say which assertions (and the
associated semantic extensions) are correct and which to use, but to me,
the same argument applies to all other languages as well (i.e.
"first-order logic could thus be considered assertional since you can see
it 'only' as a set of asserted conventions (**)" [but then, this point of
view will probably get you in a trouble with your math teacher...]).

--Ossi

(*) Well, I did suggest that the RDF model theory should use only
countable universes... :) ..so that the fuzziness related to "ordinary"
model theories could be technically avoided (I dislike the attempt to
formalise sets that are not well-defined in the procedural sense).

(**) You could easily invent a RDF-based syntax, e.g., for any first order
language (predicate and function symbols would benefit from a definition
of lists...).

P.S. I love the T-shirt ..I deeply feel sympathy for the logician(!) being
hit for asking proofs ;)


On Mon, 3 Feb 2003, Massimo Marchiori wrote:

> > #1.) RDF semantics does not define interpretation for containers or
> > collections (etc.). Since RDF semantics treats URIs as parameters, this
> > means that RDF models containers can interpreted arbitrarily. This seems
> > to nullify the work and efforts spend on defining, e.g., the rdf:bag
> > container or rdfs:comment. (From the viewpoint of entailments, why bother
> > using bag if it's "just" a URIref.)
>
> Ossi, this is the Bag/Alt issue, raised in May 2002:
> http://lists.w3.org/Archives/Public/www-rdf-comments/2002AprJun/0112.html
> AFAIK never replied yet.
> Incidentally, the same wrong argument pointed therein appears again in the current last call draft.
> Currently, unlike at the time the issue was raised, there is some additional wording on "intended mode of use" which appear as
> grey-in-the-middle ("informal interpretation"?), and should be clarified (what about interoperability?) with some razor-clear
> wording.
>
> Brian, please add this as a last-call issue, thanks :)
>
> -M
>

Received on Tuesday, 4 February 2003 03:34:45 UTC