Re: [humanmarkup-comment] FW: [humanmarkup] Base Schema - globalattributes, attribute groups and datatype definition(s)

[Rex Brooks <rexb@starbourne.com>]

Title: Re: [humanmarkup-comment] FW: [humanmarkup] Base Schem

Okay for now, but if you could remember this when we take up the new attributeGroup, I will still be bringing it up in its own separate thread for the record. This thread is still on the strawman toolkit, so if we could keep that straight, I would appreciate it.

However, I will also try to remember for the record that I think command is a type of statement not the other way around. You can have a statement that is not a command, but not a command that is not also a statement, at least verbally. Consider something as simple as "Do this," or "Don't do that." We might want to defer to an expert on thist, if we can agree on one.

Regardless, I'm still not convinced that these are attributes. I think I would prefer them to be elements in their own rights in the Secondary. I think we need to be very careful that we don't paint ourselves into a corner with this. It's another one of those things that could persuade the public that we are out of bounds trying to classify things in ways that the wider communities do not.

But I will have to give it more thought myself. It won't be long until we have the thread fired up. Our list of new elements is short and we only have this one new attributeGroup.

Ciao,

Rex

At 2:10 PM -0400 10/15/02, Ranjeeth Kumar Thunga wrote:

> Quick comment regarding enumerating the CommAtts
> attribute (set) with values and typesŠI believe it isn't worth
> enumerating values within the PSBŠalthough I was tempted to push for
> it, I believe the feedback from you and Len was that these lists
> wouldn't be truly primitive.  I was thinking along the lines of
> "statement, question, command, other", but there are others and
> finer shadesŠstatements, questions, or commands, can serve multiple
> purposes, and there are other ways of breaking down
> communication.
>  
> The only truly primitive component of communication,
> which I feel should be in the PSB at this point, is some sort of
> 'acknowledgement' attribute, with 3 possible values.
> Required - (question, command, Š.)
> Optional - (statement, declaration, Š)
> None - (rhetorical question,
> faceGesture...)
>  
> Comments?
>  
> Ranjeeth Kumar Thunga
>  
> -----Original
> Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com]
> Sent: Monday, October 14, 2002 2:46 PM
> To: humanmarkup-comment@lists.oasis-open.org;
> humanmarkup@lists.oasis-open.org
> Subject: [humanmarkup] Base Schema - global attributes,
> attribute groups and datatype definition(s)
>  
> Hi
> Everyone,
>  
> Since this
> is the last of the work for our first pass through the strawman
> toolkit HumanML Schema Len worked up for us last year, I want to take
> care of it now and ask Rob to post our list of new elements, and the
> new set of global attributes which Ranjeeth
> proposed--humlComIdentifierAtts, which I would like Ranjeeth to fill
> in with specific attributes and datatypes for values (I think he may
> want to change the attribute group name to humlComAtts since
> humlIdentifierAtts stands for ALL element names, and ComAtts is just
> for communication types, which I would like to see retricted to clear
> accepted types like: statement, question, bodyGesture, faceGesture. I
> still think this may be confusing and that each of these ought to be
> better dealt with in the Secondary Base Schema as signTypes, but we
> can discuss it. Mainly I just want it to be thought through, and not
> thrown out off the cuff so to speak. We don't have time to switch
> horses here and we will ALWAYS come up with last minute thoughts which
> give rise to anxieties that maybe we missed something. THAT's what the
> method for adding and changing the specification to be included in a
> new version of the HM.Requirements documents will do for
> us.
>  
> When I
> construct the html and the Word documents to accompany the .xsd file
> which will constitute our official namespace when approved, I will do
> my best to make these structural divisions (global attributes
> especially) easier to distinguish than currently. (Len, there's a
> question for you at the end of this message. If you can answer, fine,
> if not, also fine--I'm just lazy and there is a lot of work to
> do.)
>
>  
> Onward:
>  
> global
> attributes
>  
> We currently
> have 6 global attributes that all take (as do our elements) one set of
> dataypes. I will separate them by horizontal rules in the individual
> discussions. Even though it is an oversimplification of XML Datatypes,
> I use the usual association of name-value pairs to stand for the value
> spaces of the attributeGroupsThe 6 global attributes are:
>  
> age,
> bodyPart
> ,
> gender,
> humlIdentifierAtts,
> intensity,
> physicalDescriptors.
>

---

> Age is an
> attributeGroup defined as a set of attributes for documenting or
> determining the age of a human. This set of attributes contains two
> name-value pairs:
> dateOfBirth
> takes the datatype: xsd:date and use is required
> dateOfDeath
> takes the datatype: xsd:date and use is required
>  
> The only
> question I have with regard to Age is whether or not we want to
> annotate it to make clear that for a software agent acting as a human,
> these xsd:date values correspond to date of creation, or first
> instatiation and date of destruction.
>

---

> bodyPart is
> a simpleType takes the datatype: xsd:string
> This the
> list of specific string enumerations at present:
> arm,
> leg,
> head,
> neck,
> hands,
> feet,
> finger,
> toes,
> eyes,
> mouth,
> lips
> teeth,
> tongue,
> ear,
> earlobe,
> nose,
> chest,
> pelvis,
> buttock,
> thigh,
> ankle,
> penis,
> vagina,
> rectum,
> nostril.
>  
> The only
> question I can see with bodyPart is the same one Len included, in
> slightly different words, as to whether we wish to compile an
> exhaustive listing or refer to some other standard. I don't have an
> opinion on this. We are going to be doing an exhaustive listing and
> will include set of references to other standards or lists in the
> Human Physical Characteristic Description ML.
>

---

> Gender is an
> attributeGroup defined as a set of attributes for documenting the
> gender of a human.
> This set of
> attributes currently contains three name-value pairs:
>  
> genderAtBirth takes the datatype: xsd:string
> and use is optional (default)
> currentGender takes the datatype: xsd:string
> and use is optional (default)
> impersonator
> takes the datatype: boolean and use is optional (default)
>

---

> Human
> Identifier Attributes is is the full name for
> humlIndentifierAtts.
> humlIdentifierAtts is an attributeGroup uded
> for indentifier uniqueness and huml element names.
> This set of
> attributes contains two name-value pairs:
> id takes the
> datatype: xsd:id
> humlName
> takes the datatype: xsd:string
>

---

> Intensity is
> defined as a single attribute which stands on its own as a specific
> kind of attribute that is used by many different elements. It is used
> to set a relative scale of the intensity or strength of some emotion
> or behavior.
>  
> intensity
> takes the datatype: range
> range is
> defined separately.
>

---

> Physical
> Descriptors is an attributeGroup defined as a set of attributes fpr a
> physical description of a human.  This set of attributes
> currently includes seven name-value pairs:
>  
> height takes
> the datatype: xsd:string and its use is optional (default),
> weight takes
> the datatype: xsd:string and its use is optional (default),
> race takes
> the datatype: xsd:string and its use is optional (default),
> hairColor
> takes the datatype: xsd:string and its use is optional
> (default),
> eyeColor
> takes the datatype: xsd:string and its use is optional
> (default),
> build takes
> the datatype: xsd:string and its use is optional (default),
> scarsMarksTatoos takes the datatype: xsd:string
> and its use is optional (default),
>  
> This set of
> attributes will need to be explicitly associated with various existing
> standards and the namespaces, if any, to which those standards refer.
> In that sense it will need to belong with the elements name and
> address in the set of elements so specified. These standards include
> authentication, HR-XML, CIQ, and public safety/law enforcement. In
> this sense, this particular attribute group is slightly set apart from
> bodyParts and the Human Physical Characteristics Description ML we
> will be bulding in the future.

---

---

> There is
> currently one Datatype we define that is not part of the Built-In
> Datatypes
> (
> http://www.w3.org/TR/xmlschema-2/#built-in-datatypes
> )
>
>  
> range
>  
> dt base:
> xsd:decimal
> range [0,
> 1]
>  
> This
> specifiies a positive decimal value between 0 and 1 for establishing a
> value for the relative strength of an element in which it is
> used.
>

---

> This is
> pretty much the extent of the strawman. I admit I haven't yet given
> this as much thought as I would like, but I must leave that with you
> all for the moment. We can discuss this thread further as you like.
> However in the meantime I hope Rob finds time to post the new elements
> and the new attribute Group, and we can start taking that up
> soon.
>  
> Ciao,
> Rex
>

---

> Len, if I
> could ask, (rather than spend the time to search the archives for the
> answer which is there, I am sure), could you tell me which graphical
> editor you used to create the toolkit? While it has some features I
> like, I will probably prefer to simply write the html from scratch or
> adapt the OASIS template (not required but recommended--but which,
> oddly is vanilla html as opposed to an XHTML, which can only be had
> from an XML version put through an .xsl engine with which I am equally
> non-plussed) unless the editor is a freebie and I can find ways to get
> it to behave the way I want, at least to get me to the point where I
> can massage the raw file. Jeez, I would hate to work for
> me.
>  
>  
>  
>  
> --
> Rex
> Brooks
> Starbourne Communications Design
> 1361-A Addison, Berkeley, CA 94702 *510-849-2309
> http://www.starbourne.com * rexb@starbourne.com

--

Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com