Re: [namespaceDocument-8] 14 Theses, take 2

I just sent in response to Tim Bray another message
http://lists.w3.org/Archives/Public/www-tag/2002Mar/0016.html
which may give an example of an RDF application processing a
namespace document. That might clarify this.

----- Original Message -----
From: "David Orchard" <david.orchard@bea.com>
To: "'TAG'" <www-tag@w3.org>
Sent: Sunday, March 03, 2002 1:07 PM
Subject: RE: [namespaceDocument-8] 14 Theses, take 2


> TimBL,
>
> I want to further understand the rationale for this chain of reasoning.
My
> comments do not indicate support, they are for my clarification only.
>
> I tried to think about how software would work to do this, and what
> motivated step #5.
>
> I imagine the flow from a client software perspective is:
>
> 1. Recieve XML document with a specified namespace name.
> 2. Software processes XML document and finds namespace name.
> 3. Software decides to retrieve document at namespace name for more
> information.  This could be a Schema, Relax, RDF Schema, XLink, whatever.
> The software does not know the type of namespace name document before-hand
> (we don't have end-resource typed URIs - though this is an incredibly
common
> usage model).
> 4. Software then uses both source XML document and namespace document in
an
> application specific manner.

Yes.

> In understanding this from the RDF Schema perspective, I also came up with
> some questions and assumptions:
> 0. The usage from an RDF Schema perspective is generally around expanding
> the information wrt to the document - effectively a modularity issue.
> Otherwise I expect that the XML document would actually contain the RDF
> information.

Yes. Typically the use of a defined term in a defined vocabulary allows
a set of information about that term to be refered to by many documents
 just by using that term.

> 1. Can an RDF document refer to another RDF document for
content/modularity?
> If so, should the software follow all the "inclusions" or just one level?

RDF does not at the basic level give you "include" functionality.
DAML does, without extending RDF, just give a term (daml:includes I  think)
which is tated as a relationship between the two documents.
The agent of course is free to floow or not follow the inclusion,
but can't be said to have interpreted the entire document until it has.

> 2. How does the software know what the "type" of namespace name document
is?
> There's been some discussion on conneg, but this doesn't seem clear to me
> for the general case.  What if my software doesn't understand RDF Schema?

I thought the scenario was an RDF schema scenario.
If your software doesn't understand RDF schema, you might wonder
what it is doing dereferencing names in a semantic web document,
but I could imagine it getting an RDF schema which looks nice with
a style sheet, or maybe conneging an HTML document.

> 3. Is the namespace name document cachable?

I would expect so.

> Say I had an often used RDF
> Schema document, does it have a "time to live" or somesuch?  Is there
anyway
> of "invalidating" the cache of namespace name documents?  I'm imagining
the
> obvious case of what happens when the namespace name document changes
state.

The normal HTTP functionality applies.  To be strict, you fix the expiry
date,
wait for it, then change your document.   Or in many cases you don't
mind some people associateing version.0 with the URI and otehrs associating
version 1.01

> 4. How is security handled wrt RDF Schema documents?  Presumably the
> namespace name document server doesn't dish out namespace name RDF Schema
> documents that contain useful information (like employee information) to
> just anybody that asks.

In this aspect, a namespace really is just a document.  If it sensitive,
all the usual techniques apply, such as access control, encryption,
and so on.

> Or is the model that the RDF Schema information is
> roughly the same security level as XML Schema, that is generally publicly
> available?  Obviously this is related to question #6, 8, 9.

The technology should not enforce any correlation between security policy
and
other aspects of the document.  there will, I am sure, be confidential
XML schemata too, though less likely to contain information about people.

> 5. If the software wants to but doesn't understand the namespace name
> document, is this an error or not?  Say it's an RDF Schema, does that mean
> that the software can't proceed?  I assume the software can proceed
without
> the RDF Schema document.

That REALLY depedns what the agent is trying to do.  If it trying
to validate the original document, it has to stop.  If it is working
in a made in which it wants all its data to be valid with respect to a
digitally signed
unexpred document, it will have to stop.
In other cases, a query may well be serviced (like in XQuery)
just looking at the terms without worrying about what the
namespace owner may have said about them.

> 6. The RDF information in the namespace name document is applicable to
every
> instance of that document.  Further that this information is fairly
> "static", like an XML Schema or a DTD.  I reached this assumption because
of
> the discussions where XML Schema containing RDF Schema seemd to be of
strong
> interest to you.

Time-persistence again is an orthogonal issue.  Like with most documents,
a time-persistent one tends to be more valuable!

I was interted in RDF-schema annptation in XML schemas especialy for
the case in which the document is not encoded in RDF syntax, but
a few clues allow it to be transformed into RDF - or, if you like, the RDF
version of the information within it sucked out.

> 7. Even if the document is always available, is the software REQUIRED to
> process the namespace name document?

No.    Nor, of course, it it were to process it, would it be
expected to use live HTTP to establish the relationship betwen
URI and bits. Like with any other sorts of  document, caches and
catalogues (persistent caches) are quite in order.

>  In many WSDL/XML Schema scenarios, the
> schema validation is not done at runtime - rather the optimized software
> code validates the instance document.

Well, in many applications anyway, the application is hardwired to
process a given vocabulary. The whole software module is writen
(like an HTML browser or SVG displayer) to treat one vocabulary.
It would not dream of looking up namespace info on the fly.

> 8. Could the namespace name document be a dynamic document?  One of the
> interesting use cases I've chatting with folks about is the use of
namespace
> name documents for registry information.

yes, like any document, it could be generated from a database.


> 9. If the namespace name document is dynamic, how or would additional info
>  query params?) be passed in?  As in, get me the namespace name document
> tailored for David Orchard.

It would not IMHO be a good idea to give a different version to
differeet people - see recent mail about identity.
This breaks the expectation of identity which most people
have and could in some circumstances be considered fraud.

> 10. If the namespace name document is NOT dynamic, is there a model that
the
> static namespace name document supplies some kind of assertions and
> references to the dynamic content?

I think I have to understand your scenario and the need better to answer
this/

> 11. Is there any kind of control given to the client software over the
> contents namespace name document, kind of like browsers controlling the
> content they want render?  I'm thinking of a client wanting to "prune" the
> tree of info that is used after all the assertions have been retrieved.

In general the sorts of applications I have been building, yes there is a
lot.
Often clients filter documents as a function of where and how they found
them.

> I thank in advance for the responses.

Hope this helps!

Tim


> Cheers,
> Dave
>
>
>
>
> > -----Original Message-----
> > From: www-tag-request@w3.org
> > [mailto:www-tag-request@w3.org]On Behalf Of
> > Tim Berners-Lee
> > Sent: Thursday, February 28, 2002 12:55 AM
> > To: Jonathan Borden; Simon St.Laurent; TAG
> > Subject: Re: [namespaceDocument-8] 14 Theses, take 2
> >
> >
> > Some of the following seem to me self-evident:
> >
> > 1.  We cannot now define the languages which will be
> > available later to say
> > things about namespaces.
> >
> > 2. Human readable information is good.  Humans can sue it
> >
> > 3. Machine-readable information is good.  It allows automatic
> > processing.
> >
> > 4.  Where there is machine-readable information, it must be
> > machine-accessible from the namespace URI, either directly or
> > indirectly,
> > but without human intervention.
> >
> > 5. Where all the information available can be expressed in
> > one (not too
> > long) document then an indirection for the sake of it is an
> > engineering
> > mistake.  So clients should be prepared to accept information
> > directly or
> > indirectly, ideally.
> >
> > Now less self-evident but none the less pretty evident:
> >
> > 6. Where content negotiation is used, it should only be used
> > to negotiate
> > between documents which really are equivalent - they
> > basically say the same
> > thing in a different language.  For example, it would not be
> > appropriate to
> > give and RDF schema and XML schema for a namespace because they really
> > contain different information, and a machine or human would
> > be fooled into
> > thinking it knew the import of a document, when really it had
> > been given
> > something different.
> >
> >
> >
> > ----- Original Message -----
> > From: "Jonathan Borden" <jonathan@openhealth.org>
> > To: "Simon St.Laurent" <simonstl@simonstl.com>; "TAG" <www-tag@w3.org>
> > Sent: Wednesday, February 20, 2002 4:26 PM
> > Subject: Re: [namespaceDocument-8] 14 Theses, take 2
> >
> >
> > > Simon St.Laurent wrote:
> > >
> > > >
> > > > > TimBL made the point that if the only definitive material
> > > > > I have about my namespace is, say, an XML Schema, why
> > > > > not use that as a namespace document? i.e. why use
> > > > > indirection just for the sake of it?
> > > >
> > > > Preserving diversity at that stage in processing seems
> > like a wise idea
> > > > to me.  Indirection preserves choice by readers.
> > Recommending that as
> > > > best practice to authors seems to be more than
> > "indirection just for the
> > > > sake of it".
> >
> > Indirection doesn't preserve choice when there is only one choice.
> > When >1 document is available, then you can put an indirection in.
> > It is reasonable to change the definitive information about a langauge
> > because you get better at writing definitive information,
> > even when the
> > language has not changed.  (E.g., it is reasonable to add a
> > xml schema for
> > namespaces defined before sxmlschema was available; it is reasonable
> > to add Web ontology information to an RDF schema which
> > existed before the
> > web ontology vocabulary, and so on)
> >
> > > I strongly agree that indirection should be promoted as a
> > best practice.
> > >
> > > >From the point of view of efficiency, it doesn't matter either way:
> >
> > In what way?  An indirection costs time, and having to understand two
> > langauges adds complexity.
> >
> > [...]
> > > Jonathan
> >
> > Tim
> >
> >
>

Received on Monday, 4 March 2002 16:20:19 UTC