[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [humanmarkup-comment] Base Schema-artifact
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC