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

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup message

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


Subject: [humanmarkup] Base Schema-artifact


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

-- 


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


Powered by eList eXpress LLC