[esip-semanticweb] ESIP namespace definitions

Tue Oct 27 18:09:55 EDT 2009

I am not entirely following this.  It seems to me it is possible to  
create a mapping which supports universality, and even though some  
people may use a different approach (e.g., the '#' signs in RDF), that  
approach can be avoided when creating URIs.

For example, in the MMI RDF URIs [1], the base path could be  
considered to end in 'topicName'.  To create a URI for a particular  
term, one adds a slash and the qualified term name, like 'termOne'.

So this seems to support a 1-to-1 mapping between the two, using those  
conventions.  So for a community of use, which has specified the  
purposes to which they want to put these concepts, dual universality  
seems to be supported.

Can you explain why that is not sufficient, and why universality in  
one precludes universality in the other?

John

On Oct 27, 2009, at 1424, Benno Blumenthal wrote:

> Not to gum up the works, but a bit of information that may be useful.
>
> As it turns out, much to the surprise of many of us,  there is a  
> problem with converting (namespace,qname) pairs into URIs -- XML  
> explicitly does not define such a mapping (only the pair has  
> meaning), and different XML use-groups do it differently.   In  
> particularly, RDF and RDF/OWL use simple concatenation, while XML  
> Schema inserts a # sign in between.   So
>
> 1) RDF style namespaces usually end in a # sign or at least a  
> delimiter,
> 2) XML Schema style name spaces end in an ordinary character.
>
>
> This also means that one has to choose between URIs being universal,  
> and (namespace,qnames) pairs being universal. In other words, if the  
> URI is universal (which it is supposed to be), then the namespace is  
> not.
>
>
>
> Benno
>
>
>
>
> On Mon, Oct 26, 2009 at 3:19 PM, James Gallagher <jgallagher at opendap.org 
> > wrote:
>
> On Oct 26, 2009, at 8:48 AM, Christopher Lynnes wrote:
>
> We are now beginning to actually implement cross-ESIP applications  
> that have need of namespace declarations, specfically:
> o  Federated search
> o  Machine tagging of WMS capabilities documents
> I believe there are some semantic web applications that are not too  
> far behind...
>
> Given that permanence is a desirable feature of namespace  
> declarations, I would like to propose we settle on a definition  
> scheme that can be implemented soon, but which we expect to be stable.
>
> I would like to suggest we use a scheme like:
> http://esipfed.org/ns/foo/bar
>
> where
> o  http is the scheme
> o  esipfed.org is the authority
> o  ns indicates that it is a namespace
> o  foo/bar is a hierarchical path
>
> Examples of foo might be:
> o  fedsearch
> o  scast (for servicecasting)
> o  datatypes
>
> So for example, to uniquely identify a URI as refering to a URL to a  
> browse image (useful for typing in Federated Search) responses), we  
> might have:
>
> http://esipfed.org/ns/fedsearch/browseImage
>
> One minor downside to this scheme is that it is often useful, but  
> not required, to put an informational document, such as a schema  
> document, at the URI.  Brian, would this be feasible?  Again, I  
> don't believe it is required for a namespace URI.
>
> Any counter-proposals?
>
> A suggestion: That you include in the scheme a version number and  
> that you do it like this:
>
> http://esipfed.org/ns/foo/bar/1.0#
>
> For example, the DAP 3.3 schema has the following in the root element:
>
> xmlns:dap3.3="http://xml.opendap.org/ns/DAP/3.3#" xmlns="http://xml.opendap.org/ns/DAP/3.3# 
> "
>
> I think the version number is obvious - even HTTP has more than one  
> version. Benno and Nathan requested the trailing '#' and as far as I  
> know it exists to simplify something when building RDF although I've  
> forgotten what. Regardless, it follows the Specs and also the OASIS  
> recommendations. Maybe someone on this list can remind me regarding  
> the trailing hash...
>
> Summary: Add a version number and I forget why we have the '#', but  
> it might (will?) make working with RDF easier.
>
> James
>
> PS. Did you know that Hyrax now produces RDF? In the default  
> configuration it's not enabled but you can see it in action at  
> test.opendap.org (http://test.opendap.org/dap/data/hdf/contents.html  
> and follow the 'rdf' links; e.g., http://test.opendap.org/dap/data/hdf/S2000415.HDF.rdf) 
> . It's still in testing --> really big files break it in a nearly  
> deterministic way ;-)
>
>
> --
> Christopher Lynnes             NASA/GSFC, Code 610.2          
> 301-614-5185
>
> _______________________________________________
> esip-semanticweb mailing list
> esip-semanticweb at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-semanticweb
>
> --
> James Gallagher
> jgallagher at opendap.org
> 406.723.8663
>
>
> _______________________________________________
> esip-semanticweb mailing list
> esip-semanticweb at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-semanticweb
>
>
>
> -- 
> Dr. M. Benno Blumenthal          benno at iri.columbia.edu
> International Research Institute for climate and society
> The Earth Institute at Columbia University
> Lamont Campus, Palisades NY 10964-8000   (845) 680-4450
> _______________________________________________
> esip-semanticweb mailing list
> esip-semanticweb at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-semanticweb

--------------
I have my new work email address: jgraybeal at ucsd.edu
--------------

John Graybeal   <mailto:jgraybeal at ucsd.edu>
phone: 858-534-2162
Development Manager
Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org
Marine Metadata Interoperability Project: http://marinemetadata.org

---------------
John Graybeal
Marine Metadata Interoperability Project: http://marinemetadata.org
graybeal at marinemetadata.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-semanticweb/attachments/20091027/f4e8fdba/attachment-0001.htm>