[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

Re: [ba-ohs-talk] Fwd: CG: Common Logic Standard


Why not just "wrap" a federation mechanism in a service at a URL, and
concentrate that complexity on the server side, rather than having to
specify and implement it consistently across all the clients? Or am I
missing something?
-- 
Kevin Keck
keck@kecklabs.com    (01)


on 2002/04/08 1:42 PM, Peter  Jones at ppj@concept67.fsnet.co.uk wrote:    (02)

> This is *awesome*!
> 
> One comment though....
> 
> Referring to the following text:
> 
> John Sowa wrote:
> 
>>> 3. The globally unique URIs specified by the W3C could be used
>>> in any concrete CL syntax.  URIs may have two parts:
>>> 
>>> doc-id#frag-id
>>> 
>>> where the doc-id identifies a document and the frag-id
>>> identifies a fragment within the document.  For any concrete
>>> CL notation (KIF, CGIF, TPC, or XML-CL), the doc-id would
>>> denote some document that contains a collection of
>>> statements in that notation; and the frag-id would be
>>> some identifier defined and used in those statements.
> 
> and...
> 
>>> A: CL will provide a mechanism for breaking up a collection of
>>> statements into contexts, which can be nested arbitrarily deep.
>>> The CL identifiers will use segmented notation to specify the
>>> nested levels of contexts.  For example, an identifier, such as
>>> abc.def.xyz would represent an entity xyz in context def, which
>>> is nested in context abc.  The identifier "abc.def.xyz" would
>>> correspond to a frag-id within a CL document.  If preceded by
>>> a doc-id, it could refer to something in a different CL
> document.
> 
> The comment:
> If it is possible to have the same context, say, 'abc.def.' spread over
> more than one doc, then
> I can't request all the content in that context using only one URL
> request.
> The URL scheme is too flat.
> It would be great if some URI scheme could be concocted that didn't
> break
> present addressing methods but also empowered context-oriented requests
> that would 'gather' across doc addresses.
> I.e. I type in abc.def and get the content from
> http://aserver/doc-id#abc/def/
> and
> http://anotherserver/doc-otherid#abc/def/
> etc.
> 
> I guess that would be something a bit like a UDDI/Google, where one
> could register doc content
> and thus contexts.
> 
> --
> Peter    (03)