"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Contact information for "ResponsibleParties"

It is frequently necessary to describe parties that are responsible for some activity or object. The information will usually include names and addresses, but addition information such as "type" of the party, and customer relationship information may also be required.

This is generic stuff. It is by no means restricted to XMML. Wwe propose using a generic standard for recording this information. A suite of possibilities are described in the Cover Pages.

From amongst these, we are currently experimenting with the OASIS Customer Information Management standard.

-- SimonCox - 25 Aug 2003

Any domain schema has some interesting challenges to support uptake in different jurisdictions. Comsider for example, Australian Standard AS2490 (from dim memory - dont rely on it) for addresses, ISO19115 which includes address and contact structures, OASIS. Do you choose a domain-current-practice, technology or jurisdictional perspective to choose a standard or something else? The US federal domain may mandate use of the FGDC Address standard for example.

What about one of theses models: a) incorporating some sort of container in XMML that can be populated according to local profile b) choosing a (rich) normative form and make the adoption process register as net accessible resources a series of bi-directional transformations from XMML-global elements to XMML-myDomain profile. (and gently encourage local domains to adopt a global standard because its easier!)

IMHO, if we can crack this issue, we go a long way towards making domain schemas widely deployable.

-- RobAtkinson - 26 Aug 2003

There are two issues here from my point of view. The first is how do we incorporate a "block" of standard schema into our stuff, the second is how do we get a library of these blocks of schema.

Also note that Simon and Robert are talking on two different levels. A responsible party (general term, business associate) is a business object in the sense that it is an entity with identity. I would forsee that there would be a set of business associate modules available for use, that could be imported properly into your schema (or referenced in a business associate registry). There are some good principles and, I believe, fairly clear best practices for doing this.

The second problem, the address, is a lower level. An address is not a business object. It is a property. Another way of thinking of it is as a datatype (in OO terms). It does not have an identifier. Again, I would forsee a standard set of address assemblies that schema developers could grab as needed. In general, these should be included, but the best practices could also be worked out on these.

Putting the addresses into the business associate module again needs some work. As Robert points out, there are different addresses needed for different uses (and in different countries).

IMHO, a well developed module that needs to use a "business associate" (BA) would have a way of allowing the application schema developers to use the BA that they want. However, the BA module itself would have specific address assembly (or a choice of assemblies) without allowing the application schema developer to change them out at will.

-- JohnBobbitt - 27 Aug 2003

Online version of John's short paper outlining some possible practices for http://www.posc.org/ebiz/Guidelines/FirstIndex.html (the POSC site, but you will have to go through a couple of clicks to find the actual paper). The examples are based around the "business associate" case that is the main issue here.

-- SimonCox - 27 Aug 2003

This is the most useful and coherent conversation regarding XML deployment I have yet seen! thanks for the paper John - its very useful and confirms my gut feel about the need for the container element (option a in the suggestions above you may notice)

I'm very much focussed on what you call the "They add" - how do you deliver a community a set of modules that in turn reference other common modules, and hence by setting up the library you are actually implementing a mechanism for interoperability between communities on behalf of that community - which is a task totally beyond the remit/funding and usually skills of any real system implementor! This pattern of re-use of effort and evolution of semantic structure is consistent with "Small World Network" theory which IMHO gives a good sanity check about whether it can actually scale.

I have a couple of comments and questions arising:

1) I think I agree about the two different levels, but think they are consistent and interdependent. Using a well-known module gives meaning to the identity - it is a pre-condition to the usage patterns that will rely on object identification.

2) "Best practices" are far from clear to the broader community, and will fail to become clear until such time as real libraries are instantiated and the adherence to these practices become part of the governance framework for these. When the real value is apparent, it will be adopted. In the Marine community I could identify 500+ schemas that do not use it, and none that do!

3) I'm not sure that I agree about an address being a type - I think that addresses do have identity, they also have complex rules constraining content of sub-elements.

4) Often the structure of a module may be identical but the content rules would change - e.g. Australia uses a different set of State identifier to the US. My feeling is that there is a wrapping layer for schemas that will specify how they may be deployed in a community, and that XML-schema is not sufficient. Any ideas about best practice here?

5) You alluded to versioning, but didnt really illustrate best practice for managing versions of modules. This is particularly hard - but maybe each version becomes a first-class named object and the library will need to manage ontological relationships (and act as web service to resolve these)

-- RobAtkinson - 28 Aug 2003

Rob points out a log of things that are still in question. Let me address some of them, along with a way forward.

First of all, I put the bunch of papers I had onto the POSC web site, so that it now goes to our site, and makes available the other, related papers. See Simon's note above, or go to http://www.posc.org/ebiz/Guidelines/FirstIndex.html (the POSC site, but you will have to go through a couple of clicks to find the actual paper).

A comment on the hierarchy. At one end we have (for example) the quantityType (or measurmentType) that I worked a couple of years on. This is the idea that we can standardize on some of the simplest of things. My concept of this was that schema developers would incorporate this by "copy" or by "cut and paste," since it is so basic.

At the other end of the hierarchy is the module, such as a business associate, which is a complex type, and would be incorporated into another schema via the import mechanism.

In between somewhere is an address. The issue is, how do we incorporate it into a schema? Do we "cut and paste" it in as though it is ours (along with proper credit, of course), or do we import it and use another namespace?

My bent is to have as few namespaces as possible, so I would "tend" towards including in, rather than importing it in.

So that is the first issue: When (at what level of complexity) do we want to incorporate the new namespace by importing something?

But the other issue is more to the point of Rob's plea. I, of course, have no solution, but I think we are on the right track. The issue is, "How do we find the schema modules, assemblies, components that others have developed so that we can use them?"

There are many groups that are developing registries and metadata to describe these, but I haven't really found anyone using them. At this point, it seems to be a word of mouth. Or by national fiat (such as the FGDC statement that you MUST use their address). I would like to have a common "basic library" that anyone can use, but the devil is in the details. There are a lot of issues about how to set up the common library, and how to use it.

So I will echo Rob's plea: How do we find these common sets of schema to share? And also, how do we properly incorporate them?

comment on versioning: None. I think a lot of work has to go into versioning. If you look at the bunch of papers I have led you to, you will find that the one I did on versioning is missing, because it wasn't very good, and certainly wasn't a good solution.

-- JohnBobbitt - 29 Aug 2003

As a straw-man, here are the relevant fragments from the current version of XMML's base.xsd schema:

<schema targetNamespace="http://www.opengis.net/xmml" 
xmlns:xlink="http://www.w3.org/1999/xlink" 
xmlns:gml="http://www.opengis.net/gml" 
xmlns:cil="urn:oasis:names:tc:ciq:xsdschema:xCIL:2.0" 
xmlns:nal="urn:oasis:names:tc:ciq:xsdschema:xNAL:2.0" 
xmlns:al="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0" 
xmlns:nl="urn:oasis:names:tc:ciq:xsdschema:xNL:2.0" 
xmlns="http://www.w3.org/2001/XMLSchema" 
xmlns:xmml="http://www.opengis.net/xmml" 
elementFormDefault="qualified" 
attributeFormDefault="unqualified" 
version="pre-release">
...
  <import namespace="urn:oasis:names:tc:ciq:xsdschema:xCIL:2.0" 
schemaLocation="../oasis/OASIS CIQ/SCHEMA/W3C-Schemas/xCIL.xsd"/>
  <import namespace="urn:oasis:names:tc:ciq:xsdschema:xNAL:2.0" 
schemaLocation="../oasis/OASIS CIQ/SCHEMA/W3C-Schemas/xNAL.xsd"/>
  <import namespace="urn:oasis:names:tc:ciq:xsdschema:xNL:2.0" 
schemaLocation="../oasis/OASIS CIQ/SCHEMA/W3C-Schemas/xNL.xsd"/>
  <import namespace="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0" 
schemaLocation="../oasis/OASIS CIQ/SCHEMA/W3C-Schemas/xAL.xsd"/>
...
  <!-- ========================================================= -->
  <element name="actor" type="xmml:ResponsiblePartyPropertyType"/>
  <!-- ========================================================= -->
  <complexType name="ResponsiblePartyPropertyType">
    <annotation>
      <documentation>Description of, or link to, detail regarding 
                     people, organisations, etc</documentation>
    </annotation>
    <sequence minOccurs="0">
      <choice>
        <element ref="nl:xNL"/>
        <element ref="nal:xNAL"/>
        <element ref="cil:xCIL"/>
      </choice>
    </sequence>
    <attributeGroup ref="gml:AssociationAttributeGroup"/>
  </complexType>
  <!-- ========================================================= -->
...
</schema>

Here I have chosen to simply import components from four namespaces (nl, al, nal, cil) and have selected one global element defined in three of these to be members of a choice group, which defines the content model of xmml:actor. In order to use other name/address components, perhaps from yet more namespaces, then these will also need to be imported into this schema, and additional elements added to the choice group - i.e. it is necessary to edit this schema in order to use alternative syntaxes.

  • Graphical view of "actor" element:
    actor.png

-- SimonCox - 29 Aug 2003

And after a bit more experimentation in AdxReport, I have selected some pieces from NL and AL, as well as CIL to get a "practical" solution in that context:

  • Company uses pieces from NL and AL:
    adxCompany.png

  • Person uses pieces from NL and AL:
    adxPerson.png

-- SimonCox - 05 Sep 2003

I believe the "person" descriptor represents a person who walks in off the street, submitting a geological specimen?

A new "patient" descriptor may be required in addition to "person" to include the provision of medical references for assay data exchange. The inclusion of a "patient" would be applicable for multi-specimen processing laboratories (geochem + pathology) and provides a slightly broader and complimentary use-case of ADX data.

-- DavidHester - 26 Sep 2003

"Person" indicates the nature (type) of the object. "Patient" is a role - a Person may be a patient in a particular context, but patienticity is not their "essence" wink In GML languages we try to distinguish between nature (type) and role - Objects and Features which have a "type" are encoded using UpperCamelCase name, and their name corresponds with the UML class name; except where they are the "top-level" element in a document, an Object will always be wrapped in a lowerCamelCase element which indicates its role in relation to the parent element. Thus either a "Person" or a "Company" may play the role of "requestor". Similarly, in another document, a "Person" may play the role of "patient".

-- SimonCox - 30 Sep 2003

Let's distinguish between roles and types. And recongize the gray areas. A business associate is of type, 'person'' or company', or maybe some other types. For example, how would you type a project group within a company. Or a multi-company consortium or project. How would you classify a consultant? A consultant who has incorporated as a company? Or a government agency?

Note that any of the above can be acting in a role. As a contact. As a royalty owner. As an operator. As a project leader. As a shipper. As a "bill to". Of course, not all of the "types" can act in all of the "roles." A 'project group' would probably not be in a regulatory role. But it does help to differentiate between these concepts.

The "type" is important because it may be modelled differently. In the above, a person has an extensive name structure developed, which is not appropriate for a project working group. And a company may have a tax ID that is structured differently than a person's. So it may be appropriate to have different schemas for these different types.

A "role" is important, because that is often the head element (eg, there would be an element, 'Operator', or an element 'ShipTo', or an element, 'RegulatoryBody'.)

Finally, don't forget the relationship among business associates. A person in the role of 'contact' would also need to have the company that he is associated with recorded. The reverse idea is that a company would have a person who is the contact. A project working group would have a project manager. A person, who is the 'approval authority' role, may have another person, the 'secretary', who is an 'alternate contact.' And so on. To meet all these needs would be to develop a "business associates" database. Much of the information about these relationships might be useful (in a given exchange set), or they might not be. But a general module should allow for them, and let the user community who profile for their use to restrict to what is needed.

-- JohnBobbitt - 30 Sep 2003

The Requestor/Provider definitions are appropriate in a multi-use ADX document regardless of being explation co & lab.

I believe a "patient" element (being third party to requestor or on behalf of the requestor) is an additional type that is equally appropriate and is significantly different from a person who submits a specimen and receives the results directly.

ie A patient does not receive the results directly, as they are returned to the requestor(Doctor). The requestor requires additional specific knowledge on who the specimens relate.

The element "patient" may require re-describing to indicate a third party to differentiate the elements role/type of contained details to reduce technical ambiguities. As a "patient" may be considered both role and type?

-- DavidHester - 30 Sep 2003

Like John says, "Requestor" and "Provider" are roles, not types. A Person, or Company (including ExplorationCompany or ChemLab) may play the role of requestor in a particular transaction. Similarly, a Person may be a patient in a particular transaction, but may play other roles in other transactions.

-- SimonCox - 30 Sep 2003

ADX systems will need to be able to determine the difference between apatient and a person regardless. As a patient does not receive the results directly from the lab, the person (geo) probably will.

- DavidHester - 01 Oct 2003

There is clearly still a misunderstanding here. When a Person is a patient, then XML following the GML pattern would look something like this:

<Report>
  ...
  <patient>
    <Person id="_007">
      <name>James Bond</name>
    </Person>
  </patient>
  ...
</Report>

When a Company is the requestor then the XML would look like this:

<Report>
  ...
  <requestor>
    <Company id="WMC">
      <name>WMC Resources</name>
    </Company>
  </requestor>
  ...
</Report>

A Person may also be a requestor

<Report>
  ...
  <requestor>
    <Person id="_007">
      <name>James Bond</name>
    </Person>
  </requestor>
  ...
</Report>

The strength of the GML pattern is that the type of the object is exposed in the instance document. So objects of different types (Person, Company) can play the same role (requestor) and also a single object (Person[@id="_007"]) can play different roles (patient, requestor) in different contexts.

-- SimonCox - 02 Oct 2003

Imbedding of the role to identify the context of the data is understood.

Consider the instance below to determine results where a laboratory requires the fire-assayers to have a regular lead (Pb) blood content check.

The geo-chem lab fire-assayer/employee is requested by the geo-chem lab to see a doctor. The doctor submits and receives the results from an alternate pathology lab for the fire-assayer-patient.

The pathology lab issues copies of the report to the doctor(s) not the person/patient.

The doctor may? then re-issue the results to the patients employer, the geo-chem lab where the doctor becomes the provider and the geo-chem becomes the requestor Note: the patient-person doest not receive the results from the path lab. The patient is nested to identify the relationship to the doctor/medical service as they may visit several doctors who send the specimens to the same pathology lab.

ie example of Dr requesting results from a pathology lab.

<Report>
  ...
  <requestor>
    <Company id="XYZ">
      <name>XYZ HEALTH SERVICES</name>
      <position>Doctor</position>
      ...
      <patient>
        <Person id="_007">
          <name>James Bond</name>
           ...
        </Person>
      </patient>
    </Company>
  </requestor>
  ...
  <provider>
      <Laboratory id="ML">
        <name>Medical Laboratory </name>
        ...
      </Laboratory>
  </provider>
</Report>

Example of geo-chem shown as the requestor to the doctor/patient.

<Report>
 <requestor>
      <Laboratory id="ABC">
        <name>ABC Geochem Laboratory </name>
        ...
         <Person id="_007">
           <name>James Bond</name>
            ...
         </Person>
      </Laboratory>
  </requestor>
  ...
  <provider>
    <Company id="XYZ">
      <name>XYZ HEALTH SERVICES</name>
      <position>Doctor</position>
      ...
      <patient>
        <Person id="_007">
          <name>James Bond</name>
          ...
          </Person>
        </patient>
     </Company>
  </provider>
</Report>

-- DavidHester - 03 Oct 2003

Without analysing this case too much, I fear that you are trying to embed workflow into a document format. There is a limit to how many business rules can be represented statically, and in general it is the job of processing software to enforce rules, not the document format itself. The basic principle is that the same source information may be processed by several different applications to produce different views. In some cases the view will be "nothing", if that person is not authorised to see the information. In the examples you show here it also appears that the ifnormation model is jumbled.

-- SimonCox - 03 Oct 2003

Without wanting to dive into this to deeply myself I thought I would just mention that the OASIS standard used for Names and Addresses also has a Customer Relationship markup Language which appears to touch on some of these issues with its own solution. Might be worth a look for those of you getting in deep. It can be found in XmmlCVS:oasis/OASIS CIQ/DOCUMENTS/xCRL Standard V1_1.pdf

-- RobertWoodcock - 08 Oct 2003

The inclusion of a customer relationship is appropriate to prevent making special cases of each previously mentioned (geochemlab,exploration co, person, etc..)

I would like to table a new related topic that I beleive needs discussing which is focusing on the over-use of external links in adx.

USE OF EXTERNAL LINKS OR NOT?

This discussion may need to be moved to OtherIssues or a new topic segment entirely.

I believe the current approach of borrowing and embedding only the links in adx is a risk that needs to be discussed, irrelevant of the link purpose.

I would like to raise the technical issue of including any external domain references into the adx:report schemas. If content from other domains is required and is deemed useful, or to be formalised within adx it should be borrowed and embedded entirely, not as a pointer or reference to the internet world void.

The application and utilisation of the ADX data stream is more often than not from a very remote location eg. mining operation. Internet access as we know it today is a luxury item and is not always available for immediate access to those in the field. Who knows what server will still be available in 5 years time hosting the content currently referenced in the proposed (adx:report) schemas of today.

I acknowledge that 100% guarenteed public access to the internet would resolve this issue with 100% redundancy on all systems, however this not true in the real world or in globally hosted data.

A couple of adx use examples :

A typical case - a geologist located in a remote third world location would find imbedded external ADX schema validation links and references to outside domains counter productive. The geo would be forced to wait until they returned to the civilised office before they could process any data into their remote onsite exploration package.

Another example; I am using this next case as a lofty proposition, albeit feasable.

A Mars (the planet)automated robot explorer device is roaming the martian planet surface, processing soil samples and beaming the results back to earth in adx data streams. A practical application that is not out of the question...

The robot would need to wait extended periods for responses from various earth based servers to validate data model/support and features, before the submission and transmission of details could proceed. Being a battery and solar powered (possibly fuel cell?) device it would waste a great deal of time,energy-power and functionality trying to verify its data model prior to imbedding it in the data stream. The robot may wander about for the next +10year trying to validate against earth based servers that may/maynot be available.

The adx domain, model and schema's should be self contained for historical and future use to maximise its practical and commercial use.

ADX is a "persistant" application of xml, persistant being defined as adx data use is for both short(transient/immediate) and long(persistant/archive) term storage. Most of the present xml applications/domains are for "tranisent" or temporary use of the contained data. Where a query generates a response, the response is processed and the xml data discarded. ADX is "different" as it may be query generated, processed and then kept indefinetly in its original adx form.

Imbedding copies of required schema segments of external domains would be more appropriate for immediate and long-term historical adx applications instead of just the link itself.

I acknowledge that embedding too much model data from external links can cause problems in vast nested structures. I am concerned with the present trend of only implementing borrowed external links in Adx.

ADX should be a self-sufficient domain.

-- DavidHester - 09 Oct 2003

Related Parties - operators, clients, sponsors

I have placed the client name in generic metadata as it didn't seem correct to make it a type of operator. It would seem obviuous to me that projects would always have a client, so perhaps this could be added at the same level as operator, or maybe as part of purpose?

-- JamesPassmore - 23 Jul 2003

The "client" or "sponsor" is primarily related to the project, and only transitively to the feature being described. Thus I suggest that this information belongs with the project description, rather than as feature metadata directly.

-- SimonCox - 24 Jul 2003

We should probably have something like relatedParty paralleling the weakly typed relatedFeature property (which is present on the xmml:FeatureType etc). The role of the related party is given as the value of the xlink:arcrole attribute.

But it is also possible that a strongly typed relation like sponsor or client is a sufficiently common requirement that it should be added to the xmml:Project definition. Easily done.

Which objects and feature types should be affected?

-- SimonCox - 01 Aug 2003

The OASIS CIQ standard has a whole encoding for Customer Relationships (including company to company) which may worth either using or reviewing to assist in developing things like relatedParty.

For that matter, and I've only had a passing glance at this, the xmml:Project feature seems like a fairly common business need and may benefit from a quick review of activities in ebXML (and others) for a more "general project info" type to act as a base (or replacement) for the xmml:Project one?

-- RobertWoodcock - 04 Aug 2003

I have been working with the COSMOS/PEER group to develop an online database/ XML exchange mechanism. The AGS is aware of this group and their plans, but may not be aware of the details. Hence, a few comments.

1. We have capture Project and Site into a single entity, Site (this name was chosen as preferable to Project, since, it was stated, most engineers are familiar with Site). A Site must have one or more Holes. Thus, a Site carries the project information as well as the location etc of the Site.

2. We have pushed all "business associate" information into a separate table (object). For example, the Site might include (as does the table above) Client Name. In DB terms, this may be thought of as a natural identifier key into a table, that will include the name, phone numbers, faxes, addresses, etc of this business associate.

3. The Site Location is ill-defined, but sufficient (I think). Typically a Site is of areal extent, so the location is generally a location of a point on the Site. This point is not often defined. Note that the location is a complex data type, which consists of a datum (Coordinate Reference System), as well as the coordinates. As with business associate, the details about the coordinate reference system is kept in a different table, the the entry into the Site location is a key to this other table.

I mention these features (there are also many others) because I see a divergence growing between these groups, who, purportedly, are trying to stay together. A simple example of this is the high level model (Site has many Holes) which differs (in name, at least) to the concept of Project given above.

-- JohnBobbitt - 07 Aug 2003

For info: COSMOS/PEER-LL Workshop on Archiving and Web Dissemination of Geotechnical Data October 4 and 5, 2001

-- JamesPassmore - 14 Aug 2003
Topic attachments
I Attachment Action Size Date Who Comment
ImportingModules.htmlhtml ImportingModules.html manage 81.4 K 27 Aug 2003 - 00:39 JohnBobbitt Local copy - links using relative URL's don't work
actor.pngpng actor.png manage 9.5 K 29 Aug 2003 - 10:03 SimonCox Graphical view of "actor" element
adxCompany.pngpng adxCompany.png manage 5.2 K 05 Sep 2003 - 17:40 SimonCox Company uses pieces from NL and AL
adxOperator.pngpng adxOperator.png manage 9.6 K 30 Sep 2003 - 11:55 SimonCox Operator holds a choice of Party, Company, Person
adxPerson.pngpng adxPerson.png manage 5.4 K 05 Sep 2003 - 17:41 SimonCox Person uses pieces from NL and AL
Topic revision: r23 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).