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
on 2002/04/08 1:42 PM, Peter Jones at firstname.lastname@example.org 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:
>>> 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.
>>> 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
> 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
> The URL scheme is too flat.
> It would be great if some URI scheme could be concocted that didn't
> 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
> I guess that would be something a bit like a UDDI/Google, where one
> could register doc content
> and thus contexts.
> Peter (03)