RE: RDF in XHTML

On Fri, 20 Apr 2001, Lee Jonas wrote:

>>How do I avoid adding the same author information to every one of the
>>million pages I've written (with the aid of some monkeys)?
>
>Well, this is an entirely different prospect, and one I think that the
>'rdf:aboutEachPrefix' predicate was intended to address.

You'll have to recognize, though, that this isn't quite inheritance.
rdf:aboutEachPrefix is mediated through the hierarchical nature of URL's,
something which does not really even fit the nature of a full featured URI
implementation.

>1) Consider starting with a resource and trying to determine who the author
>was.  If this info is in a 'rdf:aboutEachPrefix' statement in some other rdf
>doc, not even referenced from the resource you are currently processing, it
>is nigh on impossible to determine.

This would seem to be the closed-world assumption at work. If we choose not
to respect it, this might not be problem at all.

>2) It relies upon the hierarchical location of resource representations -
>the granularity of what these kinds of statements apply to is too course -
>i.e. all resources whose URIs 'startWith' a common substring. It might have
>been better to do something akin to what XPointer does for XML.

My point exactly.

>Suggestion:
>IMHO rdf:seeAlso is equivalent to xsl:include semantics.  What is lacking is
>xsl:import semantics.  The latter might allow you to define a set of
>statements that apply to their current doc, then 'importing' that doc from
>another would make those same statements apply to the doc doing the
>importing.  Hence, importing a handful of rdf docs containing common
>statements (e.g. author) from a million XHTML web pages would save a lot of
>typing!

But it would not solve the problem of metadata which can be adverse to the
reputation of a resource, like restrictive PICS statements. No sane author
would rdf:seeAlso that sort of stuff. What one needs for a working Semantic
Web is a way to get to all the data that pertains to a URI, without granting
the author any real discretion.

>(Note that my current understanding of XML Schema is not perfect, I am
>hoping that XML Schema allows you to freely mix-and-match elements in
>different XML namespaces.)

It does, with the caveat that you have to have a schema permitting all of
the said namespaces.  Essentially, it makes modularization easier by far,
but doesn't really address the problem of mixed namespaces without shared
schemata (for example, XHTML and MathML). Instead it forces you to create a
schema which specifies the exact relations between those schemata. (You have
to say that a known element of a prespecified namespace can be used in a
certain context of the schema we are validating against.)

To achieve general interoperability without sacrificing accurate validation,
you would need to include something like a universal taxonomy of permissible
XML content in XSchema, so that you could declare element content models in
a truly open ended fashion (e.g. to include all printable content into the
content model of some specific element without including metadata stuff as
well). Understandably XSchema does not include this sort of thing.

Sampo Syreeni, aka decoy, mailto:decoy@iki.fi, gsm: +358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front

Received on Friday, 20 April 2001 16:06:32 UTC