W3C home > Mailing lists > Public > www-rdf-logic@w3.org > April 2001

RE: Reification

From: Peter Crowther <Peter.Crowther@melandra.com>
Date: Tue, 10 Apr 2001 10:13:37 +0100
Message-ID: <B6F03FDBA149CA41B6E9EB8A329EB12D05A10F@vault.melandra.net>
To: "'Danny Ayers'" <danny@panlanka.net>
Cc: www-rdf-logic@w3.org
> From: Danny Ayers [mailto:danny@panlanka.net]

> <- You cannot control what reads your RDF if you express something
> <- in RDF (just as with HTML or with XML).
> I believe you can.

OK, I'll go one stage further in my argument: If you embed some RDF in a
resource [for example as some annotation on a Web page] and place that
resource in a location where it is accessible from the Web, then any user
agent accessing that resource can and should get the RDF as well.  Yes, you
can play tricks with the server handing out different RDF depending on the
user agent, but there are still the usual problems of unknown UAs,
pre-caching proxies, and crawlers that use fake UA identifiers.  So I
contend that it is not, in the general case, possible to limit what a
particular agent sees.

I'd be interested to see you justify your belief in a similar way, bearing
in mind that we're talking about the Web, not about EDI between two
mainframes with a dedicated link between them.

>  That reader may not be able to cope with your
> <- range of expression, but may still try to extract what meaning
> <- it can (just
> <- as with HTML or XML); and it may get entirely the wrong 
> end of the stick
> <- (unlike HTML or XML).
> Why should it be different than HTML/XML?

HTML is designed in such a way that tags that are not understood can simply
be ignored.

XML is sort-of designed in this way, in that it doesn't pretend to carry
descriptions; it carries data.  I agree with you in one respect: two systems
implementing a particular XML application would have to agree on the
processing of a <not> tag in that XML application, just as they would have
to agree on the processing of any other tag.  But nobody really seems to
expect a system that understands MathML also to understand MyCustomML; in
fact, the very notion of XML applications reinforces this approach that a
system should cope with the entire application, or nothing at all.

RDF is not designed in this way.  From the intro to the RDF spec
(http://www.w3.org/TR/REC-rdf-syntax/, section 1):

"The broad goal of RDF is to define a mechanism for describing resources
that makes no assumptions about a particular application domain, nor defines
(a priori) the semantics of any application domain. The definition of the
mechanism should be domain neutral, yet the mechanism should be suitable for
describing information about any domain."
"Due to RDF's incremental extensibility, agents processing metadata will be
able to trace the origins of schemata they are unfamiliar with back to known
schemata and perform meaningful actions on metadata they weren't originally
designed to process."

The problem here is when a system receives some RDF, tries to do this, and
falls flat on its face because it's unaware of some nuance of the way a
property is being used within a particular piece of RDF.

> Ignore the tag would be preferable fallback, I'd have thought.

First find your 'tag'.  RDF properties are probably the closest equivalent
to *ML tags.

The problem is that you can't do this with RDF at all, because *all* the
properties carry data with uncertain interpretation.

With RDFS, a limited number of properties have some informal definition; for
example, it would be possible to use rdfs:subClassOf to extract hierarchies
from any piece of RDFS without understanding the rest.  However, if you wish
to produce any system that can answer queries about arbitrary RDF
structures, you're still screwed: without a standard definition of (for
example) negation, your system may give answers that are quite different to
those produced by a system that knows about the particular way a structure's
creator chose to express negation.

For those of us who like to produce generic solutions that we can re-sell,
this is a big problem :-).

> I see your point anyway - personally I think it would be 
> better in the case
> of uncertainty for the trumpets to sound, the drawbridge to 
> be raised and
> the oil put on the stove (or at least the transaction to be 
> rolled back).

That's fine, but 'uncertainty' in this case would have to be the discovery
of *any* piece of RDF where the system didn't know the meaning of a
property, as any unknown property could describe negation, disjunction or
some other semantic addition to RDF.  This might be theoretically
attractive, but is impractical in a world of evolving communication
standards.  Imagine a Web browser that refused to display any page that
included an unknown tag, or an XML parser that broke if the received XML
didn't adhere precisely to its own preconceived DTD or schema
specification... now imagine the same components two years down the line as
the standards have evolved.  Not a pretty thought.  I don't want software I
write to have those problems!

		- Peter
Received on Tuesday, 10 April 2001 05:13:39 UTC

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