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: HM.Requirement: authority (Re: Case in Point-culturalModule:IslamicFundamentalism?)


I'd second the use of Dublic Core. It's standard, it's been field tested, and people generally feel comfortable using it.
 
-- Kurt
----- Original Message -----
Sent: Friday, September 14, 2001 11:59 AM
Subject: RE: HM.Requirement: authority (Re: Case in Point-cultural Module:IslamicFundamentalism?)

You could use the Dublin Core to identify the source.   Characteristics of
authority are ascribed, that is, one grants authority.   So a receiver of a
message can stamp it as authoritative, or grant some entity (eg, a
university, some scholar, etc) as an authority.   Then the source and
the authority are joined records for that message.
 
The next level is the authority to create types.   This is the choice
of choices issue.  For example, we have granted OASIS the
brandability of our work.  They in turn have granted members
resources.   These are assertions the existence of which
enables one to mark these messages as transiting within the
scope of the contract.   The contract has created certain
relationships and these are governed by rules which can be
checked to validate that a behavior is of a type within the
scope of the contract and verify that some instance of that
behavior is valid to that type.    Its particular representation
in some media may be styled.  XSLT is a means to transform;
the properties of the target of that transformation are its style
properties.  
 
It is important to define/ascribe a scope (view dimensions) within which messages are
exchange and to create a test by which one can verify that
the message is reacted to in a valid way.    In the message
from Satwinder Mangat  there are several view dimensions.
He also describes a culture (a sikh culture), rules for dress,
and behavior, symbolic artifacts, etc. all of which one could
use to create a HumanML description of his view of this
culture as described in his message.   He provides enough
information to test whether or not some person, behavior,
artifact, message, etc is valid within that view.   In fact,
that is the message he wants to convey:  that members
of this culture are to be differentiated from another.  So
he has created dimensions corresponding to opponency
although not one of conflict.   He also notes that there
are overlaps in these groups which may create a false
or superstitious interpretation.
 
There is quite a lot to work with there.
 

Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h

-----Original Message-----
From: Ranjeeth Kumar Thunga [mailto:rkthunga@humanmarkup.org]
Sent: Friday, September 14, 2001 1:20 PM
To: humanmarkup-comment@lists.oasis-open.org
Subject: RE: HM.Requirement: authority (Re: Case in Point-cultural Module:IslamicFundamentalism?)

"Dynamic schemas" is the way I am capturing this thread...representing different perspectives based on established patterns.
 
Here is an instance of a perspective (i.e. authority) 'module' I came up with-- for lack of a better word at this stage.
These can describe each XML Schema.  RDF is used to annotate XML documents, but has it also been used for annotating XML Schemas themselves?  I still have some past threads and reference to study regarding RDF related to HumanML, but this is a question that now pops up for me.
 
The 'bias' factor has to made explicit at the onset.
 
<perspective type="??" date="09.02.2001" extrapolation_type="direct inquiry" />
         <individual>Bill Jacobs</individual>
         <individual>Representative John Billy</individual>
         <individual>Senator Joe Whiter</individual>
         <group>US State Dept</group>
         <group>Canadian Gov't</group>
</perspective>
 
DTD (for simplicity sake, for now)...
  
<!DOCTYPE [
<!ELEMENT perspective (individual*, group*)>
<!ELEMENT individual #PCDATA>
<!ELEMENT group #PCDATA>
<!ATTLIST perspective type CDATA #REQUIRED>
<!ATTLIST perspective date CDATA #REQUIRED>
 
<!--Choices below include assumption, direct_inquiry, ModelX, ModelY, algorithmX, patternZ, or anything else-->
<!--It may describe how the perspective was derived-->
<!ATTLIST perspective extrapolation_type CDATA #REQUIRED "assumption"
 
]>
 
(of course, digitally signed and verified through a mechanism--possibly such as what Sean was developing)
 
I don't think in a practical sense we will need to deal with so much complexity as Paul's research was directed towards--at least to get the initial perspectives flushed out  (although time will tell).  
 
I don't think we will need to get too abstract either.
 
In other words, I don't think we need to establish abstracted pattern matching models to describe perspectives, or utilize mathematically tranform perspectives (Len:  when you use the word stylistic modifications, I am assuming you mean transforming through XSLT correct?)
 
It is much better to let the humans themselves define them directly, as Rex has been emphasized previously, through individuals themselves.   As humans, we polarize towards what is concrete anyway, for better or for worse.  If authority is clear and unequivocal, we start to share a common perspective.  Patterns start to merge and come together, and the complexity relating to differences may not seem so complex. 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC