[Zope3-dev] Re: Better access to APIs in paths (was Re: needingviewsclues - template/title troubles)

[Eric Roby]

We are using Zope as our foundation for developing Semantic Web solutions
which entail developing/managing/distributing knowledge bases.  Working with
namespaces is crutial.  Currently, we develop these ontologies (abstract
classes) outside of Zope, export them as RDF-S ( our data model) , run them
through a python application which translates the RDF-S into python classes
which are hosted within Zope as a product.  We are about to begin merging
ontologies to make new ontologies which means that we now have multiple
namespaces to deal with.  All these details of multiple namespaces is hidden
by the Zope product.  We intend to be able to leverage inference engine
search technology and to do that we need to be able to publish the instance
data back out as RDF, OWL and DAML-OIL. These are currently just handled as
views via controllers.  In addition, we also have to be able to geospatially
enable the knowledge bases.  This requires adding (yet) another namespace
based on GML (Geography Mark-up Language). Namespaces are crutial...

The point of this ramble is that I think Shane is right-on here... xml
namespaces must be able to be handled in the most natural way possible.
dc:title or FGDC:title or FGDCBII:title makes absolute sense to anyone
involved with Semantic Web.  I don't know enough about Zope 3 to understand
if it will make our efforts more productive in this regard.  The notion of
being able to create API's specific to namespaces we develop sounds very
intriguing.  Part of our efforts goes into developing validation methods to
provide element level quality control.  Unless I am mis-interpreting the
context of this whole thread - our QC methods could be roled up and exposed
to our knowledge bases as an API.  Am I totally out to lunch here???

Eric

Shane Hathaway wrote:

> Jim Fulton wrote:
> > In the example I have, dc was just an API namespace. Later in my note,
> > I said I wouldn't actually use that. I'd use:
> >
> >   context/api:title
> >
> > or just:
> >
> >   context/:title
> >
> > Given arguments made elsewhere about how unsophisticated the audience
> > of this feature is, I wouldn't expect them to be thinking in terms of
> > adapters.
>
> The audience would be thinking in terms of avoiding Zope-specific
> references where possible, though.  Without namespaces, Evan's great
> string formatter example isn't very good anymore, since it has to rely
> on a big, changing API:
>
> <span tal:content="item/total/:money">$10,000.00</span>
>
> Can we come up with all useful string formatters (and all their
> permutations) for the first release of Zope 3?  Of course not.
> Namespaces let you depend on specific versions of a relatively small
> API, and that API can be implemented without the rest of Zope.  So how
> would you write the above code without adding a "money" API function?
> (If you have to write some Python code to do it, what is the gain over a
> namespace declaration?)
>
> Namespaces used this way are like Python import statements.  People
> don't find "import sys" to be a burden, so if we use easy-to-remember
> namespaces, why are namespaces a burden?
>
> Don't get me wrong--I support and understand your position.  But I think
> people find namespaces a lot more appealing than they used to, since
> virtually every new XML schema in the past three years uses them heavily.
>
> Shane
>
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope3-dev