Subject: RDF/XML Media Type registration draft
From: gk at ninebynine.org (Graham Klyne)
Date: Tue Jul 29 17:24:23 2003

Aaron,

Following some informal discussion in the RDFcore working group, I'm 
sending these as personal review comments to you, and to the MIME types 
review list...

Concerning:
[1] 
http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-02.txt

Broadly, I think this looks fine, but the RDFcore working group has made a 
number of changes to the RDF specifications in response to last call 
comments since the above MIME type registration draft was issued.  The 
following comments would, in my view, help to bring the proposed MIME type 
registration more closely in line with the current RDF specification status.

Section 2, 3:
The citation for the RDF data model is to the RDF Semantics document 
[2]:  the definition of the abstract syntax has now been moved to the RDF 
Concepts [3], and I think that would now be a more helpful citation.

Section 3:
Would it be appropriate to cite the RDF Semantics in the interoperability 
considerations section? E.g.
[[
RDF is intended to allow common information to be exchanged between 
disparate applications.  A basis for building common understanding is 
provided by a formal semantics [2?], and applications that use RDF should 
do so in ways that are consistent with this.
]]

Section 4:
In response to last-call feedback, we decided to pull the "social context" 
material from Concepts.  I think that it would be appropriate to also pull 
it from the MIME type registration;  i.e. remove all of section 4.

Section 5:
Would it be appropriate to cite RDF Concepts here? cf:
   http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/#section-fragID

Regards,

#g
--

[1] 
http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-02.txt

[2] http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-mt-20030117/
(current editor's working draft)

[3] http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/
(current editors' working draft)

At 10:23 24/07/03 -0500, Aaron Swartz wrote:
>I'm soliciting comments on the media type registration draft for
>RDF/XML:
>
>http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml- 
>mediatype-02.txt
>http://www.aaronsw.com/2002/draft-swartz-rdfcore-rdfxml-mediatype -02.html
>
>As required by section 2.3.1 of RFC 2048, I've sent it for review to
>ietf-types and ietf-xml-mime.  Dan Connolly says the document has
>undergone sufficient W3C review because it is [referenced from the
>syntax draft].  However, I'm happy to take any comments from the WG or
>other W3Cers/RDFers at the same time. Do folks think sending a note to
>www-rdf-interest or something would be in order?
>
>[ref]
>http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/#section-MIME- Type
>
>I plan to fold in all the comments I receive and release a new version
>in two weeks. (After that, I need to ask the IESG if they want to do
>their own Last Call, wait for RDF to go to Recommendation, update the
>draft to refer to the Recommendation, and then submit it to be
>published as an RFC.)
>
>--
>Aaron Swartz: http://www.aaronsw.com/

-------------------
Graham Klyne
<[email-masked]>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

From: gk at ninebynine.org (Graham Klyne)
Date: Tue Jan  3 16:22:35 2006
Subject: RDF/XML Media Type registration draft
Message-ID: <[email-masked]>

Aaron,

Following some informal discussion in the RDFcore working group, I'm 
sending these as personal review comments to you, and to the MIME types 
review list...

Concerning:
[1] 
http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-02.txt

Broadly, I think this looks fine, but the RDFcore working group has made a 
number of changes to the RDF specifications in response to last call 
comments since the above MIME type registration draft was issued.  The 
following comments would, in my view, help to bring the proposed MIME type 
registration more closely in line with the current RDF specification status.

Section 2, 3:
The citation for the RDF data model is to the RDF Semantics document 
[2]:  the definition of the abstract syntax has now been moved to the RDF 
Concepts [3], and I think that would now be a more helpful citation.

Section 3:
Would it be appropriate to cite the RDF Semantics in the interoperability 
considerations section? E.g.
[[
RDF is intended to allow common information to be exchanged between 
disparate applications.  A basis for building common understanding is 
provided by a formal semantics [2?], and applications that use RDF should 
do so in ways that are consistent with this.
]]

Section 4:
In response to last-call feedback, we decided to pull the "social context" 
material from Concepts.  I think that it would be appropriate to also pull 
it from the MIME type registration;  i.e. remove all of section 4.

Section 5:
Would it be appropriate to cite RDF Concepts here? cf:
   http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/#section-fragID

Regards,

#g
--

[1] 
http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-02.txt

[2] http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-mt-20030117/
(current editor's working draft)

[3] http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/
(current editors' working draft)

At 10:23 24/07/03 -0500, Aaron Swartz wrote:
>I'm soliciting comments on the media type registration draft for
>RDF/XML:
>
>http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml- 
>mediatype-02.txt
>http://www.aaronsw.com/2002/draft-swartz-rdfcore-rdfxml-mediatype -02.html
>
>As required by section 2.3.1 of RFC 2048, I've sent it for review to
>ietf-types and ietf-xml-mime.  Dan Connolly says the document has
>undergone sufficient W3C review because it is [referenced from the
>syntax draft].  However, I'm happy to take any comments from the WG or
>other W3Cers/RDFers at the same time. Do folks think sending a note to
>www-rdf-interest or something would be in order?
>
>[ref]
>http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/#section-MIME- Type
>
>I plan to fold in all the comments I receive and release a new version
>in two weeks. (After that, I need to ask the IESG if they want to do
>their own Last Call, wait for RDF to go to Recommendation, update the
>draft to refer to the Recommendation, and then submit it to be
>published as an RFC.)
>
>--
>Aaron Swartz: http://www.aaronsw.com/

-------------------
Graham Klyne
<[email-masked]>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

From: coomes at math.miami.edu (Dr. Brian Coomes)
Date: Tue Jan  3 16:22:35 2006
Subject: Proposed new MIME type classifications
Message-ID: <004d01c353c2$aab204a0$0600a8c0@aphrodite>

Phaser Scientific Software, LLC (www.phaser.com) proposes the creation of
two new MIME type classifications for proprietary "document" files used by
the Phaser program.

The MIME types proposed are:

application/vnd.phaser.gallery
application/vnd.phaser.project

We are attempting to comply with the procedures for MIME type registration
outlined in rfc1590.  If there is more to be done, please let us know.

We appreciate your feedback. 

Best regards,
Dr. Brian Coomes
Department of Mathematics
University of Miami
Coral Gables, Florida 33124
(305) 284-6987
[email-masked]

From: coomes at math.miami.edu (Dr. Brian Coomes)
Date: Sun Jul 27 00:10:23 2003
Subject: Proposed new MIME type classifications
Message-ID: <004d01c353c2$aab204a0$0600a8c0@aphrodite>

Phaser Scientific Software, LLC (www.phaser.com) proposes the creation of
two new MIME type classifications for proprietary "document" files used by
the Phaser program.

The MIME types proposed are:

application/vnd.phaser.gallery
application/vnd.phaser.project

We are attempting to comply with the procedures for MIME type registration
outlined in rfc1590.  If there is more to be done, please let us know.

We appreciate your feedback. 

Best regards,
Dr. Brian Coomes
Department of Mathematics
University of Miami
Coral Gables, Florida 33124
(305) 284-6987
[email-masked]

From: me at aaronsw.com (Aaron Swartz)
Date: Tue Jan  3 16:22:35 2006
Subject: for review: RDF/XML Media Type registration draft
Message-ID: <[email-masked]>

In accordance with section 2.3.1 of RFC 2048, I'd like your comments  
and feedback on our draft registration of a media type for the W3C's  
RDF/XML format. The Internet-Draft is at:

http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml- 
mediatype-02.txt
or, more permanently,
http://www.aaronsw.com/2002/draft-swartz-rdfcore-rdfxml-mediatype 
-02.html (or .txt or .xml)

RFC 2048 recommends comments "on the choice of type/subtype name, the  
unambiguity of the references with respect to versions and external  
profiling information, and a review of any interoperability or security  
considerations."

I'll respond to feedback for two weeks and on August 8th I'll release  
an updated Internet-Draft folding in all the changes.

Thanks,
-- 
Aaron Swartz: http://www.aaronsw.com/ww

From: me at aaronsw.com (Aaron Swartz)
Date: Thu Jul 24 17:01:52 2003
Subject: for review: RDF/XML Media Type registration draft
Message-ID: <[email-masked]>

In accordance with section 2.3.1 of RFC 2048, I'd like your comments  
and feedback on our draft registration of a media type for the W3C's  
RDF/XML format. The Internet-Draft is at:

http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml- 
mediatype-02.txt
or, more permanently,
http://www.aaronsw.com/2002/draft-swartz-rdfcore-rdfxml-mediatype 
-02.html (or .txt or .xml)

RFC 2048 recommends comments "on the choice of type/subtype name, the  
unambiguity of the references with respect to versions and external  
profiling information, and a review of any interoperability or security  
considerations."

I'll respond to feedback for two weeks and on August 8th I'll release  
an updated Internet-Draft folding in all the changes.

Thanks,
-- 
Aaron Swartz: http://www.aaronsw.com/ww

From: distobj at acm.org (Mark Baker)
Date: Tue Jan  3 16:22:35 2006
Subject: Request for advice: sbml+xml Media Type
In-Reply-To: <[email-masked]>; from [email-masked] on Fri, Jul 04, 2003 at 08:22:00PM -0700
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Ben,

On Fri, Jul 04, 2003 at 08:22:00PM -0700, Ben Kovitz wrote:
> 1. Would it be a bad idea if we used RFC3236 (The  
> application/xhtml+xml Media Type) as a model for the document w  
> write?  I'm hoping that we don't need to explain the full  
> semantics of SBML in the RFC, since there are already some  
> weighty papers that do that (referenced above).  At only 8 pages,  
> RFC3236 seems like a model of simplicity and clarity that we  
> would like to emulate.

I'm not sure I'd agree, but thanks!

>  Or is it possible to get even simpler?  
> Some of the docs I found for XML MIME media types seemed to do  
> little more than list the name of the type and who submitted it.  

There's a continuum, of course.  For RFC 3236, Peter and I went out of
our way to include all the pertinent information that we felt was
required by the media type registration process.  The problem with
this, of course, is that some information in the specification needs to
be duplicated in the registration.

Luckily, this issue was recognized by the IETF, and more recent
W3C-initiated media type registrations are using a "shell" registration
document which permits the IANA media type registration form to be
included within the W3C-maintained specification.  See, for example, the
SOAP registration;

http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-03.txt

Unfortunately for you, I don't think this would apply, as I believe
this arrangement is fairly unique between the W3C and IETF, or
at least between the IETF and other similarly trusted organizations.

> 2. We are thinking of including required parameters of "level"  
> and "version".  Anything to watch out for here?  Is this a wrong  
> idea?  SBML has multiple levels to enable different simulation  
> tools to interoperate at different levels of complexity and  
> sophistication.  Each level can come in different versions.  More  
> levels are planned.  

In my observation, these rarely work out as extensibility mechanisms.
text/html used to have one ("level"), and it wasn't used, so wasn't
included in RFC 2854.  application/xhtml+xml has one ("profile"),
but it's there for a single purpose only; to help WAP apps distinguish
between XHTML Basic and XHTML 1.0.  I'm not aware of anybody using it
for other reasons.

You might want to consider whether prescribing sufficiently extensible
processing behaviour - such that "higher level" (more complex) content
may be properly processed by a "lower level" processor - would be
adequate for your needs.  Feel free to contact me off-line if you'd
like some advice on how that might be done.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>From [email-masked]  Sun Jul 20 22:32:38 2003
From: triad at df.lth.se (Linus Walleij)
Date: Tue Jan  3 16:22:35 2006
Subject: Request for advice: sbml+xml Media Type
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 4 Jul 2003, Ben Kovitz wrote:

> Some of the docs I found for XML MIME media types seemed to do
> little more than list the name of the type and who submitted it.

This is indeed the case. However: these exist for historical reasons,
and also because the responsible people are very pragmatic about
things. When the IESG decides whether to pass the RFC or not, they will
get back to you and ask you to produce an RFC that describes the content
of this transport type (they did with me).

Thus the lengthy documents refered (inaccessible to me right now) should
preferabley reside with some standards body, IETF RFCs are preferred,
W3.org documents come next, IEEE standards have been referred (e.g.
audio/mpeg etc.)

I believe the reason as to why a standards body, and IETF in particular,
should be used as a storage holder for the standard spec is that it should
be easily and readily accessible by any contemporary AND FUTURE
implementors of this standard. Compared to IETF, the current storage of
the specification (Sourceforge in your case) is rather new and not
generally known as an eternal document store. (My inability to obtain
it right now is an indication of its reliability.) This means e.g. URI:s
referenced in your transport type could change and at a future date
complicate the process of retrieveal for an external party, and the IETF
cannot guarantee access to these vital documents, which is bad.

If you do not want to submit the entire specification to the IETF as an
RFC, prs.-types or vnd.-types should be used instead.

If you can argue well for you case, then I believe eventually the IESG
will make an exception, but this may take a considerable amount of time.

Most of this stems from personal experiences and opinions, so take it
simply as a piece of anecdotal knowledge, other people here will probably
amend and correct me extensively.

Linus

From: distobj at acm.org (Mark Baker)
Date: Mon Jul  7 09:10:08 2003
Subject: Request for advice: sbml+xml Media Type
In-Reply-To: <[email-masked]>; from [email-masked] on Fri, Jul 04, 2003 at 08:22:00PM -0700
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Ben,

On Fri, Jul 04, 2003 at 08:22:00PM -0700, Ben Kovitz wrote:
> 1. Would it be a bad idea if we used RFC3236 (The  
> application/xhtml+xml Media Type) as a model for the document w  
> write?  I'm hoping that we don't need to explain the full  
> semantics of SBML in the RFC, since there are already some  
> weighty papers that do that (referenced above).  At only 8 pages,  
> RFC3236 seems like a model of simplicity and clarity that we  
> would like to emulate.

I'm not sure I'd agree, but thanks!

>  Or is it possible to get even simpler?  
> Some of the docs I found for XML MIME media types seemed to do  
> little more than list the name of the type and who submitted it.  

There's a continuum, of course.  For RFC 3236, Peter and I went out of
our way to include all the pertinent information that we felt was
required by the media type registration process.  The problem with
this, of course, is that some information in the specification needs to
be duplicated in the registration.

Luckily, this issue was recognized by the IETF, and more recent
W3C-initiated media type registrations are using a "shell" registration
document which permits the IANA media type registration form to be
included within the W3C-maintained specification.  See, for example, the
SOAP registration;

http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-03.txt

Unfortunately for you, I don't think this would apply, as I believe
this arrangement is fairly unique between the W3C and IETF, or
at least between the IETF and other similarly trusted organizations.

> 2. We are thinking of including required parameters of "level"  
> and "version".  Anything to watch out for here?  Is this a wrong  
> idea?  SBML has multiple levels to enable different simulation  
> tools to interoperate at different levels of complexity and  
> sophistication.  Each level can come in different versions.  More  
> levels are planned.  

In my observation, these rarely work out as extensibility mechanisms.
text/html used to have one ("level"), and it wasn't used, so wasn't
included in RFC 2854.  application/xhtml+xml has one ("profile"),
but it's there for a single purpose only; to help WAP apps distinguish
between XHTML Basic and XHTML 1.0.  I'm not aware of anybody using it
for other reasons.

You might want to consider whether prescribing sufficiently extensible
processing behaviour - such that "higher level" (more complex) content
may be properly processed by a "lower level" processor - would be
adequate for your needs.  Feel free to contact me off-line if you'd
like some advice on how that might be done.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>From [email-masked]  Sun Jul 20 23:32:38 2003
From: triad at df.lth.se (Linus Walleij)
Date: Sun Jul 20 22:32:43 2003
Subject: Request for advice: sbml+xml Media Type
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 4 Jul 2003, Ben Kovitz wrote:

> Some of the docs I found for XML MIME media types seemed to do
> little more than list the name of the type and who submitted it.

This is indeed the case. However: these exist for historical reasons,
and also because the responsible people are very pragmatic about
things. When the IESG decides whether to pass the RFC or not, they will
get back to you and ask you to produce an RFC that describes the content
of this transport type (they did with me).

Thus the lengthy documents refered (inaccessible to me right now) should
preferabley reside with some standards body, IETF RFCs are preferred,
W3.org documents come next, IEEE standards have been referred (e.g.
audio/mpeg etc.)

I believe the reason as to why a standards body, and IETF in particular,
should be used as a storage holder for the standard spec is that it should
be easily and readily accessible by any contemporary AND FUTURE
implementors of this standard. Compared to IETF, the current storage of
the specification (Sourceforge in your case) is rather new and not
generally known as an eternal document store. (My inability to obtain
it right now is an indication of its reliability.) This means e.g. URI:s
referenced in your transport type could change and at a future date
complicate the process of retrieveal for an external party, and the IETF
cannot guarantee access to these vital documents, which is bad.

If you do not want to submit the entire specification to the IETF as an
RFC, prs.-types or vnd.-types should be used instead.

If you can argue well for you case, then I believe eventually the IESG
will make an exception, but this may take a considerable amount of time.

Most of this stems from personal experiences and opinions, so take it
simply as a piece of anecdotal knowledge, other people here will probably
amend and correct me extensively.

Linus

From: bkovitz at caltech.edu (Ben Kovitz)
Date: Tue Jan  3 16:22:35 2006
Subject: Request for advice: sbml+xml Media Type
Message-ID: <[email-masked]>

Hi,  
  
I work on SBML (Systems Biology Markup Language) at Caltech.  We  
are thinking of proposing a new XML MIME media type.  
  
When learning about the process for getting a new IETF-tree media  
type approved, I was strongly advised to consult the members of  
the ietf-types and ietf-xml-mime discussion lists for advice  
before diving in.  So here I am.  I'll appreciate any advice you  
can give me, especially any that saves us from making some stupid  
mistakes that the biological modeling community will regret for  
years to come.  Please forgive me if I reveal my ignorance in  
some questions below.  

First, a little background.  SBML is an XML format for  
representing systems of biochemical reactions.  Making it a MIME  
media type would enable browser-based simulation tools to  
conveniently download, run, and edit models.  Work is now  
beginning on a web infrastructure to make it easy for biological  
researchers to share models on the web, download models used in  
published papers, etc.  
  
Two "levels" of SBML have been defined so far.  Specifications,  
including the XML schemas, are at:  
  
http://www.sbw-sbml.org/sbml/docs/papers/sbml-level-1-version-2/sbml-level-1.pdf  
http://www.sbw-sbml.org/sbml/docs/papers/sbml-level-2-version-1/sbml-level-2.pdf  
  
We are thinking that the ideal name would be either:  
  
   application/sbml+xml  
  
or:  
  
   model/sbml+xml  

Now, here are a few questions.  
  
1. Would it be a bad idea if we used RFC3236 (The  
application/xhtml+xml Media Type) as a model for the document w  
write?  I'm hoping that we don't need to explain the full  
semantics of SBML in the RFC, since there are already some  
weighty papers that do that (referenced above).  At only 8 pages,  
RFC3236 seems like a model of simplicity and clarity that we  
would like to emulate.  Or is it possible to get even simpler?  
Some of the docs I found for XML MIME media types seemed to do  
little more than list the name of the type and who submitted it.  
  
2. We are thinking of including required parameters of "level"  
and "version".  Anything to watch out for here?  Is this a wrong  
idea?  SBML has multiple levels to enable different simulation  
tools to interoperate at different levels of complexity and  
sophistication.  Each level can come in different versions.  More  
levels are planned.  
  
3. Is it completely stupid to even consider model/sbml+xml?  The  
other model/ media types have been for spatial models.  SBML is  
primarily used for spatial models of reactions that occur within  
biological cells, and has some notions of spatial relation, but  
an SBML model does not necessarily have the minimum 3 orthogonal  
dimensions specified in RFC2077.  We're wondering if SBML is  
still within the spirit of the model/ top-level content type,  
though.  RFC2077 speaks of economic models, behavioral models,  
and so on, and seems to encourage a situation where modeling  
tools might work successfully on models from radically different  
domains.  
  
4. Any other advice you'd care to offer?  

Thanks in advance for your assistance,  
  
Ben  
  
--  
Ben Kovitz  
Systems Biology Workbench (SBW) Development Group, Caltech  
http://www.sbw-sbml.org  
bkovitz at caltech.edu  

From: bkovitz at caltech.edu (Ben Kovitz)
Date: Sat Jul  5 05:22:05 2003
Subject: Request for advice: sbml+xml Media Type
Message-ID: <[email-masked]>

Hi,  
  
I work on SBML (Systems Biology Markup Language) at Caltech.  We  
are thinking of proposing a new XML MIME media type.  
  
When learning about the process for getting a new IETF-tree media  
type approved, I was strongly advised to consult the members of  
the ietf-types and ietf-xml-mime discussion lists for advice  
before diving in.  So here I am.  I'll appreciate any advice you  
can give me, especially any that saves us from making some stupid  
mistakes that the biological modeling community will regret for  
years to come.  Please forgive me if I reveal my ignorance in  
some questions below.  

First, a little background.  SBML is an XML format for  
representing systems of biochemical reactions.  Making it a MIME  
media type would enable browser-based simulation tools to  
conveniently download, run, and edit models.  Work is now  
beginning on a web infrastructure to make it easy for biological  
researchers to share models on the web, download models used in  
published papers, etc.  
  
Two "levels" of SBML have been defined so far.  Specifications,  
including the XML schemas, are at:  
  
http://www.sbw-sbml.org/sbml/docs/papers/sbml-level-1-version-2/sbml-level-1.pdf  
http://www.sbw-sbml.org/sbml/docs/papers/sbml-level-2-version-1/sbml-level-2.pdf  
  
We are thinking that the ideal name would be either:  
  
   application/sbml+xml  
  
or:  
  
   model/sbml+xml  

Now, here are a few questions.  
  
1. Would it be a bad idea if we used RFC3236 (The  
application/xhtml+xml Media Type) as a model for the document w  
write?  I'm hoping that we don't need to explain the full  
semantics of SBML in the RFC, since there are already some  
weighty papers that do that (referenced above).  At only 8 pages,  
RFC3236 seems like a model of simplicity and clarity that we  
would like to emulate.  Or is it possible to get even simpler?  
Some of the docs I found for XML MIME media types seemed to do  
little more than list the name of the type and who submitted it.  
  
2. We are thinking of including required parameters of "level"  
and "version".  Anything to watch out for here?  Is this a wrong  
idea?  SBML has multiple levels to enable different simulation  
tools to interoperate at different levels of complexity and  
sophistication.  Each level can come in different versions.  More  
levels are planned.  
  
3. Is it completely stupid to even consider model/sbml+xml?  The  
other model/ media types have been for spatial models.  SBML is  
primarily used for spatial models of reactions that occur within  
biological cells, and has some notions of spatial relation, but  
an SBML model does not necessarily have the minimum 3 orthogonal  
dimensions specified in RFC2077.  We're wondering if SBML is  
still within the spirit of the model/ top-level content type,  
though.  RFC2077 speaks of economic models, behavioral models,  
and so on, and seems to encourage a situation where modeling  
tools might work successfully on models from radically different  
domains.  
  
4. Any other advice you'd care to offer?  

Thanks in advance for your assistance,  
  
Ben  
  
--  
Ben Kovitz  
Systems Biology Workbench (SBW) Development Group, Caltech  
http://www.sbw-sbml.org  
bkovitz at caltech.edu