OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup-comment message

[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