[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [humanmarkup] RE: [humanmarkup-comment] Base Schema-artifact
The schema itself is a set of nouns if you want to go down a path
of trying to think of it as a spoken language, but it actually isn't.
It is a data object description. It is important to keep the data
definitions, classification of properties of interest, separate from
the ways in which they may be applied. All the schema should
be concerned with is those property sets which can affect a
human communication, that is, creates a context for that
act or actions. The rules that can use these property
sets vary enormously depending on the type of interest.
In effect, the schema classifies the kinds of codes that
will used.
Be wary of 'verbizing' nouns (thinging). That is an object implementation
and has value, but a simulation and a relational database
aren't the same level of implementation. Someone trying
to collect information based on a standard code set,
someone implementing a simulation using that collected
information, and someone creating analysis reports based
on that collected information aren't doing the same job.
In the current draft, the original intent was to name the
observable or inferred properties of a human communication
such that all the other jobs could be done using the
rules (say, business rules or policies) of the particular
tasks.
len
From: Rex Brooks [mailto:rexb@starbourne.com]
Hi Everyone,Since much of the discussion on artifact has occurred in replies to other threads, I am going to gather up that discussion here with the proviso that I am not going to quote paragraphs, just names, dates, the thread Subject from which it was taken and the time it was posted working forward from the earliest to the latest. Please excuse the disjoint character, but I wanted to collect only the discussion relating to Base Schema-Artifact, so Dr. Candelaria deRam's exposition on Base Schema-Address should be reviewed for the context of those comments, and especially for the abstract discussion of HOW our schemata, Primary and Secondaries needs to be understood and how it perhaps, ought, to be modeled.Note: There are on-going discussions throughout these threads that deal with the way or manner in which we are building the overall Human Markup Language Suite or Set of Schemata, including, though rarely addressed specifically while we are concerned with XML Schemata, RDF--which I wanted to mention as another aspect which we will need to be dealing soon.Please, if you have more artifact-specific thoughts, please reply to this message to preserve the thread, and delete portions of previous posts with which your comments are not concerned.Thanks,RexOn Sun, 19 May 2002 11:38:34 -0500, Rob Nixon, Subject:Assorted meeting notes, wrote1). ARTIFACTS:
a) The "meaning" assigned to an artifact can change over time.
b) The derived meaning at any given time is associated with the cultural
framework in which it is considered.
c) There can be many parallel (in time) meanings assigned to an artifact,
with each meaning deriving from different cultural (or group) frameworks.
d) It's possible that an Artifact can act as more than a noun in that an
Artifact can act (and I would argue almost always act) as a "signal"
within the perceptual field of the perceiver.
e) As an overly simplistic model, Artifacts can be thought of as the
nodes of a network, with beliefs acting as the connections between the
nodes. Clusters of these nodes and connections, can be thought of as
context, with the entire network viewed as the knowledge and experience
of the individual perceiver.
f) By treating each network as a surface(of arbitrary dimension) we can
add time into the model as a series of stacked surfaces with the
"artifact" nodes connected to their corresponding nodes in the surface
"beneath". The evolution of the meaning of the "Artifacts" over time can
be viewed as a series of vectors, where these vectors may fork, continue
through, or dead end ( as the artifacts may separate into multiple
artifacts upon examination, remain consistent, or actually be lost in the
physical or in memory). This process can be viewed as a type of Cellular
Automata (CA).
g) These connected series of vectors can be thought of as a trajectory
through the knowledge and experience "space" of the individual
perceiver. You will also find that there is a type of "momentum"
associated with these trajectories as groups of related "artifacts" and
the connecting beliefs about those artifacts reinforce each other. It
takes more to shift the perspectives (in relation to the artifacts) as
time goes on if they have been reinforced.
h) It should also be understood that each individual perceiver can beviewed as a node in a cultural and social network (which is hierarchicalin nature) with (feedback loops) interconnecting the artifact nodes (and beliefs ) among the interacting individuals.
i) Artifacts can also act as a pointer to a series of Metaphors, or in
and of itself act as a "Metaphoric" node.
j) In essence a (manufactured) Artifact can also be viewed as the
"condensation" of "meaning" out of the knowledge and information field of
the individual or the group.
k) It is also important to understand that when we are dealing with"Artifacts" (objects) within Virtual Simulations, the concept of linear
time and cause and effect can no longer be viewed as it has been
traditionally.
If for example I am running a series of simultaneous "Simulations" each
based on a specific time period ( i.e. 1920, 1930, 1940, 1970, 1993,
2002) and I share an (Artifact - a book, a building, a coin) "object"
among them (that contains "Static Data Members", "Static Member
Functions" ) I will run into a problem with potential cause and effect if
we use a simple linear view of time.
The following example should highlight the problem:
If for instance my six simulations utilize a class of object called
"Book", each of the six simulations will contain their own object
"instantiations" of the book class. You can think of the "Book Class" as
the Archetype of a Book, and each instantiation of the Book Archetype in
each simulation as the "physical manifestation" of the Book Archetype.
In this sense each of the books in the six different simulated periods
have no relation to each other (other than "Bookness") and therefore can
not effect each other. However, if we include data and functions called
"Static Data Members" or "Static Member Functions" in our Book Class (
Archetype ), then we create a link between ALL instantiations of books in
ALL simulations.
The reason for this is that the Static Data Members and Functions are
associated with the CLASS and not the individual book objects in each
simulation. So if we had (for what ever reason) static data members
called "Highest Catalogue Number" and "Date Assigned" which were used to
assign the next instantiated books catalogue number in any given
simulation, all books everywhere in all simulations would access that
"Highest Catalogue Number". Here is the problem, let us say for the
sake of argument that when we start our six simultaneous simulations (
ie. Boston - 1920,1930, 1940, 1970, 1993, and 2002 ) that it just sohappens that the first "book" object is instantiated in the 1970
simulation. The catalogue number "1" is assigned to that book instance,
and the date of "April 5, 1970" is recorded in the Static Data member
called "Date Assigned".
Now it just so happens that since the start of our six simulations the
next instantiation of a book occurs in the 1930 simulation. The local
simulation sees that there has already been one book assigned, and so it
updates the "Highest Catalogue Number" to 2. What it discovers however
is that from it's (the particular simulations perspective) the first book
was assigned 40 years in it's future, so in effect, it has experienced
and effect from the future. A simple time stamping of events in this
case would lead to chaos and confusion. Now if we update the Date
Assigned for this second instantiated book to Feb 23, 1930, from the
perspective of the 1970 simulation it has just had it's past changed bysomething occurring in the 1930 simulation.(concluding):The previous points have been greatly simplified for clarity ( I hope ).
The goal of the previous points have been to illustrate that the concept
of an "Artifact" as a simple noun is insufficient. I believe that
rather than viewing an (artifact)/"Signal" as an interruption in a static
field (as was discussed during the meeting), that they should be viewed
as semi-recurrent / semi-stable dynamic "processes" (or eddies) in a
fluid field (where "fluid" describes a dynamic network structure.)On Mon, 20 May 2002 10:54:38 -0500, Len Bullard replied in that thread:Doing this quick so not enough time to be simple. I'm
not enthralled with "verbs" in XML Schemas. They don't
belong there. On the other hand, nouns created by an
XML Schema do have to participate in relationships and
verbs as business rules, etc., certainly have to be
considered. I guess I see schemas almost like property
sheets; just data objects.
First, be sure these topics can diffentiate a data standard
from a system specification. If we mix up these levels, we
will never emerge. XML is strictly a naming system that
includes a structural means to organize names. Insofar asverbs can be named, they can be XMLized, but the object model
of XML is not very good when it comes to doing things like
DAGs. So artifacts as "nodes in a network" is a description
more amenable to RDF possibly.
1. Meaning, semantic. Is always assigned regardless of
time. It is always system specific, or view specific.
2. A system may have a cultural description the currency
of which may correspond to some shared data values but
this is not required nor explicitly a norm. That is,
the context of human communication is always personal,
or more to the point, rooted to individuals.
3. An artifact may be a sign or a symbol. It is
not a signal except insofar as it is an interruption
in an observer's view. One might say it acts in that
context initially, but I'm not sure that is very useful.
An artifact is a noun. It may be a property of some
process. (really, an artifact is just a way to group
a set of non-random assemblies of substances that
are made by humans. The term is very vague but was
put there to include things such as jewelry, clothing,
etc.).
4. Building a state machine description of a communication
is fine. Choice of choices with rules operating over each
transition. Again, not very XML and possibly not very
relevant to the schema except insofar as the schema describes
the names and structures of messages/state representations
passed among nodes in the network. Differentiate intelligent
choices (choice of choices: a well-defined process operates
over the selection) from interpretable acts, or simple
observables (we know this person did this, but we cannot
name the rules of the process, only inspect the outputs
at some declared set of transitions).
5. Because meaning is always "assigned", time is a context
property important to interpretation where interpretation
requires a view definition. No argument there.
Time is independent of instantiation insofar as identitybased on type is concerned. Apriori use of a class such
as book does not infer a place in time, just a set of
properties for the classification. Yes, it is importantnot to create "effects from the future" as a side effect
of instantiation. Nothing should prohibit it as a kind
of artifice (time machine novels are what they are). Time
itself, is just "previous" and "next" if we deal with
it linearly. Time affects instancing based on type if
the type, not the instance, has evolved and that evolution
is time-ordered for the purpose of identifying it. It is
possible to timestamp an event, classify it as a type of
incident, and move on to other forms of interpreted
classification. For example, an observable or
reportable event is recorded, an incident declared that
requires a response (eg, call for service), and later,
that incident is classified as say, a type of culturalact (eg, a crime type, murder, rape, etc.)To which, on Mon, 20 May 2002 11:34:20 -0500, Rob replied:Thanks Len,
Regarding: 3. An artifact may be a sign or a symbol. It is
not a signal except insofar as it is an interruption
in an observer's view....
I would argue that MANY, if not most Artifacts can be considered to be a
"compressed" signal form, especially if it is within the prior experience of
the perceiver. I don't think that an "interruption" in an observer's view
actually will cover it. In fact, I'm not sure I know what "an interruption
in an observer's view" really means... The pattern of photons reflected off
the object, the tactile feel of the object, the smell of an object, even a
written or audio description of the object all act as signals which are then
decoded and processed via the pattern recognition structures of the brain (
or A.I. algorithms). They are not just static tags. Nothing is static.
Perhaps I'm being too literal here. Or I am missing the point. But I would
also point out that there are developers who have already expanded on the
concept of an Artifact as noun "only"... and many are going that direction
in the VR realm (which we must be able to support). i.e. The "Artifacts" in
"The Sims" ( i.e. Refrigerator, Paper, Sofa, Shower, etc. ) do act assignals to the environment ( specifically the virtual humans ). These
artifacts "broadcast" their "benefits" to the "Sims" in the environment and
the virtual humans respond.
Again, I am trying to make sure that we don't lock ourselves into aninterpretation of a concept that may actually be evolving.
Thanks,RobTo which in turn, on Mon, 20 May 2002 16:11:54 -0500, Len replied:The example for signal was something
like breaking an electrical field to make a Morse code. This
gets tendentious quickly. For example, there is a person
on the other side of the cube drumming their fingers on the
desk. Is this signal? In the sense that it is "drawing
attention" yes; in the sense that it conveys information,
explicitly, no. One can interpret it, eg, significator of
boredom or nervousness, but unless it is organized into
some kind of regular beat with duration, one might not interpret
it as Morse. Signal requires more properties to be
interpretable, that is, to make an optimum choice, we
need more than just signal. It is a dark and stormy night and
we are driving across the Ponchatrain at high speed.
Up ahead, we see someone waving excitedly. We have
to choose:
1. Stop. There is an emergency.
2. Drive on. This is a nut or a robber.
Only as we are plummeting into the swamp do we
understand they were signaling an emergency based
on the bridge being down. It is a bit late.
Pattern recognition and the optimum choice are
not simple problems.
A piece of jewelry is initially exactly just an interruption.
It attracts attention. It may have symbols on it and these
may be readily interpretable. Otherwise, it is decoration.
Training is everything. Knowing the difference between a sign
and a signal is a training issue (apriori experience). A
sign should be obvious to someone trained to recognize it.
The only really compelling property of a signal is thatit "attracts attention" and can be made to carry information,
but in and of itself, is just a media-type noise when
first noticed that has to be correlated to be interpreted.
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'm not sure we can make that schema handle the notion
of "broadcasting value". I can see an implementation
of an object-oriented communication that does that.
We may find that the abstractions of signal, sign and
symbol are inappropriate and turn to simply, messages,
but then again, we may find that messages are aggregatesof the above.Meanwhile, in her post on Base Schema-Address and Artifact, Dr. Sylvia Candelaria deRam, wrote:Intro.
Now the HumanML committee has moved [from "phase 0", discussion] into
the stage of actual schema design for HumanML.
Thus saith Rob Nixon:
At 11:38 AM 19-05-2002 -0500, you wrote:
>Hello everyone, sorry for the delay.
>
>Here are a few notes related to the discussion we had during our monthly
>HumanML Technical Committee conference call on the 15th. Many of these
...>speak in the
>languages of physics, mathematics, and systems sciences,
...
> also overlaps with the concepts underlying the semantic web approach.
>
>These notes are not meant to send us wildly off course, but rather to
>make sure that we have explored our assumptions.
>>1). ARTIFACTS:
>... [marvelous exposition, q.v., referred to in part below]....
Per Rex Brooks and Ranjeeth Thunga's guidance, we've begun jointly
re-working through the caderie of possible terms for HumanML. Today in
our conferenced telephone meeting note was taken that since our problem
is handling the "human" which is invariably also contextual, a shallowlist of terms such as suitable for some other markup endeavors is
patently insufficient. How, then, to proceed to bring contextualizationinto our base of primaries (cf. primitives)?
The following analysis of the first term under discussion, ADDRESS, sets
it up as RELATIONAL, with CONTEXT CONDITIONS.
It turns out to be amazingly consonant with Rob Nixon's concurrent
discussion of the second term, ARTIFACT.
Rob's point j) describes how an ARTIFACT is "manufactured" ... "out of
the knowledge and information field of the individual or the group". His
points g) and h), speaking of 'trajectories' zooming "through the
knowledge and experience 'space' of the individual perceiver" [who is,
themself,] "a node in a cultural and social network...with (feedback
loops) interconnecting the artifact nodes and beliefs) among the
interacting individuals" propose the interesting idea of "momentum"
within a dynamic net.
When an ADDRESS is a special case of an ARTIFACT, as I'd opined in our
phone meeting, Rob's description of ARTIFACTs in terms of nets are thus
illustrated by the concrete "semantic-net-portions" for ADDRESS set out
below. Elaboration on contextualizable nets follows, and then somequestions to work from.<snip--captured in entirety in Base-Schema-Address thread>C.related working term: ARTIFACT
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>At 7:00 AM -0700 5/14/02, Rex Brooks wrote:
Hello again,
I'm continuing along with our examination of the Base Schema a little more quickly than I probably will as we go along in order to get you all used to the process and to keep it in front of your eyes, hopefully to encourage a bit more participation. Please note that even though we have not in any sense exhausted discussion on the first element, address, I am continuing on. Hopefully we will hear more voices about whether we need to specifically associate that element with existing address systems and whether residential v. postal v. email or all three and more need to have specific attributes defined within the element. Another note in favor of participation now: it is easier to be heard in a smaller group than a larger. So participate while you can.
That is part of the idea here. If you don't notice how an element is important to you now, and we don't fully qualify that element for your eventual use later, we are going to have many more problems with our implementations than if we all put in the skull sweat now, while the process of making changes and adjustments is a whole lot easier than it will be once existing implementations rely upon the way these elements are defined for use now.
In other words, don't look beyond your mirrors for the the culprits responsible for not defining an element the way you need it later if you don't put in your $.02 now. Nuff Said.
So, our second element:
artifact
This is a Complex Type with the attribute of abstract which means an element cannot use it directly but must use it as a complexType derived from this complexType.
This becomes somehat more clear in the annotation which specifies that it is a specifically "Human" Artifact, of, or relating to, Human use in communicating the depth of contextual information that HumanMarkup is designed to do. Examples are objects such as clothes, jewelry, pictures, trinkets which express interests, hobbies, status or lifestyle--to which I would add cultural affiliations in particular.
It is further specified that is a member of the xsd:attributeGroup referenced by "humlIdentifierAtts"
As a base element, artifact is very important because it forms the basis for a whole host of secondary schemata elements. The presentation of an individual is always a case of context since without an audience, even if one is simply admiring or examining one's self in a mirror, presentation cannot exist, at least in a pragmatic sense, as opposed to a logical conundrum, and I would suggest that we are not really chartered to engage in that kind of argument unless it is necessary to produce a pragmatically useful result.
I am wondering if another related element might be called for in the base schema, which I was going to bring up eventually regardless of when or where in the list it occurred. That is comes up with the second element is propitious.
This is an element such as artifice as a verb, or another verb for the act of creation, which would also be an abstract complex type allowing for all manner of Human creation.
And this in turn introduces an entirely new thread, in which I will ask that we not indulge in relation to artifact, because we will arrive at it in due course when we get to the element: signal.
The primary reason I bring it up now is to forestall an entirely separate and inappropriate set of arguments that could probably be brought up for every element we discuss. That is the apparent lack of verbs in the base schema. I would prefer, if we can, to hold that discussion in abeyance until we get through the entire list we have because our base schema is not currently configured to include operators, and operators, or the lack thereof, is such a large field that I think we would get bogged down in it and this will give us all, especially those of us concerned with specific subcommittees and secondary schemata a chance to look at the set of operators we each will want and to think about what the base elements for those operators will need to be.
There, I've gone and put my foot in it.
Ciao,
Rex
--
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
--
--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC