Re: [humanmarkup-comment] Base Schema-artifact

[Rex Brooks <rexb@starbourne.com>]

Clarification: My calls for discussion don't at this point mean that 
I want or think we need to settle on a precise xsd definition of a 
particular element for our schema per se, although if we arrive at a 
good consensus, we can leave that thread as settled, which requires 
no further action on anyone's part at that point.

It is, however, necessary, if we want to say that we have reached 
that point of a settled consensus on an element to put it into 
well-formed xsd format. For elements which are included in the 
existent schema, we need to have an amended coding for that element 
put forward upon which we can settle. This is Len's perogative. We 
can then just leave that thread until we gather the entire document 
up for an official draft and vote and recommendation.

Is that agreeable?

As for the prospective definition here for artifact, I don't have a 
specific objection, but I do have a strong desire to know that our 
definition is in agreement with general use in anthropology, 
archeology, cognitive science, AI Studies. Or at least does not 
conflict with such definitions and usages.

It is not that I am against adding new dimensions or breaking new 
ground for any term, only that it not break with current best 
practices or academic usages. Artifact is just such a term, and the 
concept of address as subform is a fairly unusual interpretation, 
which needs additional explanation for our audiences. In fact this 
approach below could be very useful as a method. If I could get Manos 
to explore it as a way to build a Topic Map of Associations for our 
xml elements, it would probably also be useful for helping build an 
RDF Schema as we go along.

One thing that Sylvia's work continues to point up for me is that we 
need to attempt to keep a running expostulation of our work if we 
can, to improve the understanding of it when we present it. I have 
suggested to Philip to include textual explanations of his work, and 
Rob has already done so, as has Sylvia.

We can use our mailing list for this purpose, as well, but I ask that 
we use a separate threading for that purpose, such as "Thoughts on a 
hetnet of or for Humanmarkup."

However, on a purely practical note: I belong to several mailing 
lists, and while I send my both plan and styled, I try to avoid 
allowing my browser to send html, since I get my chops busted for 
that on a regular basis whenever I do, so I would really appreciate 
it if we refrained from including markup in our posts except when 
giving coding samples or obvious humorous points. I will try to find 
my sense of humor, one of these days, honest.

Ciao,
Rex


At 8:54 AM -0600 5/22/02, cognite@zianet.com wrote:
>Rex calls for any further urgent points on Artifact:
>
>Looks to me like we still need something specific, for people to use as a
>taking-off point in implementing apps.  Let's try to figure out a simple but
>general term-entry for ARTIFACT to be used in the context of our accumulated
>presuppositions such as Rob's Artifact points a-j and other group members'. 
>
>Suppose we start with a dictionary-entry-like format and move it into a
>contextualized process rule format -- trying for a groundable [semantic]
>heterogeneous net rule if possible.
>
>The perspective in the following definition would include the examples from
>the phase-0 one like jewelry but is perhaps more all-purpose, and takes some
>of the recent comments into account, as noted below. 
>
><PRE>
>==========================================
>ARTIFACT:  a trace of significant activity
>
>
>"trace":  residue that may be chemo-physical; may be social or cultural or
>mental construct.
>
>"activity":  happenings; in particular, actions of social beings (??)
>      [with the consequence that the activity can have co-operative 
>significance]
>
>"significant":  in "an interpretant context"  (see below)
>
></PRE>
>
>---------- prior discussion material re interpretant context:
>
>
>Date: Mon, 20 May 2002 13:56:16 -0600  cognite
>
>       comment: A particular ADDRESS is an [instance of an]
>>>       ARTIFACT. ADDRESS is a kind of ARTIFACT (cf. ISA, AKO, subclass).
>>>       In having to do with significant (maybe even purposive) activity
>>>       it differs from being a plain location.
>>>       It has co-operative significance: That "human" social
>>>       property ;).================<snip>
>>>       -------------------------------------------------------------
>
>Mon, 20 May 2002 16:11:54 -0500, Len
>
>       Yes, an artifact can be a compressed means, but I would
>>>       argue it is a sign or probably a symbol if it contains a
>>>       lot of information.  Without an interpretant context, one
>>>       can't say.  For example, the notion that an address is
>>>       symbolic is interesting only if within a culture or
>>>       learning set, an address has acquired a meaning,
>>>       eg, prestige address, slum, business area, gangland,
>>>       whatever.  It is not an artifact per se unless we
>>>       dumb down artifact to mean "thing".   Otherwise,
>>>       the first primary association of address is to
>>>       a geoLocation.  Other relationships depend on the
>>>       system.
>
>I.e., we want to keep that social "significance" of the trace in the
>description, make sure it's in the rule (or whatever we're calling these
>term descriptions).
>
>
>What kind of thing would we get when "interpretantizing" the
>dictionary-style definition above?  First, look at what might be done with
>ADDRESS; then, try to generalize from it to incorporate said definition.
>
>For ADDRESS, extracting generalities from address apps in widespread use had
>led to the following contextualized net portions.   (Those apps had used
>simple association-list, form, Pascal-style labeled-entry record-structures
>to hold
>[static, "dumb"] data.) ADDRESS was blithely considered to be a special case
>of ARTIFACT....
>
><PRE>
>General interpretive process was:
>
>referror [signifior] ----/situation including current ROLES
>----> reference NAME(s) or DESCRIPTION(s) [sign/symbol]  [of REFERENT,
>signifie']
>
>===ADDRESS====
>
>{contact method ---/situational conditioning
>---> contact location specifier(s) }
>= ADDRESS (with underlying situated processing)
>
></PRE>
>
>Note:  We can make the whole, within {} and including processing for
>particularizing conditions of time, space, person(s), mindset(s) and the
>like, be the ADDRESS "node" when considered a dependency graph node in a
>heterogeneous net.
>
><P>
>
>Now then, let's try to generalize this ADDRESS rule.  Might lead to
>something like this; at this stage, let's try various wordings.
>
><PRE>
>=====ARTIFACT=======
>
>observation method --/conditions --> artifact specifiers (situated, 
>interpreted)
>
>Restated:
>
>{observation --/conditions --> trace item(s) with attributed meaning }
>= ARTIFACT
>
></PRE>
>
>Notes: 
>
>- The social significance is vested in the *attributed meaning*; it stems from
>the conditions of evaluation that tie the definition, when applied, to its
>context(s).
>
>- The trace object itself is of course not the same as the DESCRIPTION of it
>that we are calling ARTIFACT. It's the REFERENT.
>
>- The whole, within {}, is the ARTIFACT "node" (if we can assume groundable
>hetnet). 
>
>- Whether the processing is implemented with classes or RDF or production
>rules or whatever is left unspecified.  That fits our design spec.
>
>- The available capacity for XML to go off and do processing can be used
>this way, can't it?
>
>
>How usable do you all think these might be? 
>
>How suitable is this particular description (v. dictionary-style entry)?
>
>SC
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


--