[esip-semanticweb] [Esip-federatedsearch] ESIP namespace definitions

[Christopher Lynnes]

Matt,
    There are more things going on in ESIP that utilize namespaces  
than just the Federated Search effort.  The machine tagging of WMS  
capability documents is one such effort just beginning in the Air  
Quality cluster (http://wiki.esipfed.org/index.php/Recommendations_for_Semantic_Web_Markup_of_Existing_XML 
).  Servicecasting, an effort to advertise services spearheaded by  
Brian Wilson, is another.  There are also ongoing ontology  
developments with ESIP.
    I am proposing a common namespace, but with a hierarchy, so that  
each effort can define its own namespace extensions as necessary, but  
so that we will also be able to utilize each other's namespaces where  
appropriate.  Servicecasting is likely to be an early case of that.

On Oct 26, 2009, at 11:16 AM, savoie at nsidc.org wrote:
>
> Chris (et al.):
>
> I'm a little confused by this proposal and it may be entirely due do  
> my
> experience level or the fact that I wasn't at the recent meeting, so
> please bear with me.
>
> Are you proposing defining the namespace declaration for a set of
> cross-ESIP extensions to OpenSearch?  Something along the lines of the
> geo and time extensions to OS.
>
> How many different namespaces would there need to be?  I would have
> assumed we could get away with one namespace for the extension and  
> then
> defined withing that extension the pieces we needed.
>
> So something like:
>
> http://esipfed.org/federatedsearch/1.0/
>
> would be all that was necessary to describe the extensions that we are
> using.
>
> So I may be missing the point completely since I'm not sure what
> "machine tagging of WMS capabilities documents" actually means.
>
>
> But if I am off base completely, I would suggest a version number in  
> the
> namespace at the very least.
>
> Cheers,
> Matt
>
>
>
>
>
> Christopher Lynnes <Chris.Lynnes at nasa.gov> writes:
>
>> 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?
>> --
>> Christopher Lynnes             NASA/GSFC, Code 610.2          
>> 301-614-5185
>>
>> _______________________________________________
>> Esip-federatedsearch mailing list
>> Esip-federatedsearch at lists.esipfed.org
>> http://www.lists.esipfed.org/mailman/listinfo/esip-federatedsearch
>>
>>
>
> -- 
> Matthew Savoie  -  Scientific Programmer
> National Snow and Ice Data Center
> (303) 735-0785   http://nsidc.org

--
Christopher Lynnes             NASA/GSFC, Code 610.2          
301-614-5185