Re: Divide the problem

At 10:50 AM -0400 6/9/00, John Cowan wrote:
>On Fri, 9 Jun 2000, David G. Durand wrote:
>
>>  I'll also note that namespace-named-by can be the identity function,
>>  because a namespace itself is a _purely_ abstract resource that has
>>  only self-identity and uniqueness as properties.
>
>Who says so?
>
>Namespaces can have lots of properties: inventedBy, createdOnDate,
>obsoleteAsOfDate, previousVersionOf, nextVersionOf, usedInSchema.
>Though perhaps not favouriteDrink.
>
>Or by "properties" do you mean "necessary/essential properties"?


Exactly. In the standards universe of discourse, we can only sensibly 
talk about properties that are part of an object's definition (by 
some standard) and that can be counted on by all who encounter it. 
The namespaces specification attributes to a namespace only the 
property of having a string associated with it, and endorses only the 
operation of literal comparison for determining identity of 
namespaces.

In fact, the ability of namespaces to bear many accidental(*) 
properties, and for schemas to do so as well, is part of the reason 
that we need to define a language for describing namespaces and all 
their properties, before we go trying to resolve URIs to their names.

To go back to a running example, if I invent a URI space labelling 
bricks on the Brown University Campus (or even a global 
campus-brick-location URI space), then I can't go retrieving those 
URI's over the wire until I've defined what brick meta-data might be, 
and created a MIME-type to indicate that, so that I can get back a 
useful result for that retrieval.

If I fail to do that, it's not well-defined what retrieval of such a 
URI would mean: Do I fetch the brick or data about the brick? 
Skipping data encapsulation issues :-) we'd at least need a MIME-type 
to determine if we were receiving a brick or data about the brick. At 
least, as long as your name isn't Ignatz.

For an abstract object this ambiguity does not arise, one can _only_ 
retrieve descriptions of the object, and thus it's even more 
important to define the language for those descriptions. If we 
_don't_ define such a well-known language, interoperability will be 
impossible because the results of the retrieval will be of an 
unpredictable data type, encoded in many posible languages.


   -- David

(*) Accidental properties are ones that are not inherent to an 
object's self-identity. This distinction is often used to 
disrtinguish essential properties of an object from ones that are 
changeable. Containing (most of) a particular piece of leather is an 
essential property of my shoes, while being on my feet is an 
accidental one.
-- 
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
http://cs-people.bu.edu//dgd/             \  Chief Technical Officer
     Graduate Student no more!              \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
                                              \__________________________

Received on Friday, 9 June 2000 11:59:46 UTC