NB: CogEnv and CIDOC CRM Classes and Properties v. 3.4.2

[cognizor@cognizor.com]

I have a question for all you expert app builders.  But first I'd better explain where it's coming from.  

(We might be able to address it in today's teleconference, as another agenda item
under subcommittee stuff, being as how we're all on all of them now.  It might need written material, though.  It's part of CogEnv work.)  OK, now to be a bit more formal:

-----
TOPIC:
	The Conceptual Resource Model Class and Property schedule bears examining in relation to the needs of HumanML Cognition in Environments (CogEnv).  (Latest posted is 3.4.2 at http://ics.forth.gr, version almost ready to go as ISO std. submission is in the works, 3.5.)

For now, as CogEnv's work begins to build a vocabulary for applying huml terms and extending and refining that vocabulary for applications in the scope of Cognition in Environments, a concrete beginning might be using the CRM as part of a straw-man vocabulary; that approach served well when we used Len's nucleus for the base-level huml schema.  The CRM has been thoroughly thought out with an eye to use in computer applications dealing with archives of artifacts of importance to human societies.  Its formal symmetry will be an advantage, and is organized similarly to an XML schema specification.  (Our changing it would not interfere with it as an XML spec, though.)

----------------------------
Examining CRM for CogEnv Use:

	So I've begun studying the CRM and putting its CRM double structure into computable form.  (Using python ;) Appended is the CRM Class and Property Hierarchies table, extracted to text for computer reading.)

	CRM BASIC FORM
In brief, so far the form of CRM appears thus:
	A series of Entities serves as Domain and Range pairs for Properties.  Each Entity and Property boasts associated definitions with ample examples of where and when they may apply.
The slant toward describing artifacts being archived is evident in that structure.  (There are some 84 Entities and 140 Properties.)
	Relations among the Entities are arranged for RTF (which is given in another auxiliary big file), so instead of n-ary relations, there are many component levels to achieve binary branching (because of RTF's limit to 2 arguments for each relation).  Both Entities and Properties have cross-over re-uses, however, so the CRM is a tangled hierarchy.
	Relations are directed, so besides the multi-level indicators, you see paired phrasing names -- for example, in the accompanying DTD of Properties (Relations), there is one tagged F and an alternately-worded one tagged B (for Forward and Back, presumably).  In this and other ways, the terms inventory is perhaps oriented more toward computational logic than the human and hard science that will be required to characterize cognition well:  

	For example, these are not sub-classed:

P130 shows features of (features are also found on) 
	with arguments E33 Linguistic Object and E33 Linguistic Object

P45 consists of (is incorporated in)
	E18 Physical Stuff and E57 Material

P69 usually employs (is usually employed by)
	E29 Design or Procedure	and E57 Material

P72 has language (is language of)
	E33 Linguistic Object and E56 Language


	The examples below are finer grain as well as subclassed (max levels they show is 3 for P, 8 for E).  Ownership is slanted toward the particular practices and culture that underlie museums.


P49 has former or current keeper (is former or current keeper of)
	E18 Physical Stuff and E39 Actor

	P50 - has current keeper (is current keeper of)
		E18 Physical Stuff and E39 Actor

P51 has former or current owner (is former or current owner of)
	E18 Physical Stuff and E39 Actor

	P52 - has current owner (is current owner of)
		E18 Physical Stuff and E39 Actor

	??? - has current owner (is current owner of)
		E28 Conceptual Object and E39 Actor

One technique to use this in CogEnv would be to expand it by adding terms in similar ways.  For us, an obvious lacuna could be:

P72 has language (is language of)
	E33 Linguistic Object and E39 Actor

where we connect E39 Actor to huml:Human and somehow thence to huml:HumanGroup.  (These no longer appear, though they were incorporated at the CRM SIG in DC in March that Jim and I participated in.)

A large sub-tree has been developed describing [archiving] events under P12, which might bear expansion in the manner of the suggested ??? map that I added in above as a possible extension of the P51 family.

P12 occurred in the presence of (was present at)
	E5 Event and E77 Persistent Item

	P11 - had participant (participated in)
		E5 Event and E39 Actor
	
		P14 - - carried out by (performed)
			E7 Activity and E39 Actor
		
			[Only title and custody events specified]
	...

	P31 - has modified (was modified by)
		E11 Modification Event and E24 Physical Man-Made Stuff

		P108 - - has produced (was produced by)
			E12 Production Event and E24 Physical Man-Made Stuff
		P110 - - augmented (was augmented by)
			E79 Part Addition and E24 Physical Man-Made Stuff
		P112 - - diminished (was diminished by)
			E80 Part Removal and E24 Physical Man-Made Stuff

Modifying (P31 family) is paralleled by brought into/took out of existence, used specific technique, used specific object, and moved, as well as had participant, but for CogEnv, further expansion would be called for.  The same applies to P15 was influenced by and P19 was intended use of, where huml terms for Intent and so forth would appear to fit in.

----------------------
App Structure Question:

OK, now you see the picture that's emerging, if I've explained enough.  I'm trying to apply the techniques we used to build our base vocabulary, plus extend them to the secondary level where apps are to be part of the picture.  Our HumanPhysicalCharacteristicsDescriptionX (HPCD???) sub-committee has Rex's app, but AFIK its linkage to a terms inventory is still being elaborated, so this is exploratory, looking for an approach to connect huml vocab and app.

However, my question to you at this point is:

Having rendered Entities as classes (with the many cases of relations among them rendered just as shared parents so far),

would you render Properties also as classes?  

If so, would the change in levels you see in them (as above) show as mixin classes?  (Alternatives would seem to be inheritance or subclassing or mixin classes.)

Merci.  <humly-yrs>

SC
-- 
 ;););) blessed are the geeks -- for they shall inherit the source code :):):)