RE: [set] Groups - A Discussion on Dale Moberg's comments (DaleMoberg.pd

These are all good observations. I can add that the next release of jCAM editor has a consistency evaluation tool - that will show the type of thing you introduce here - the ability to sanity check schema and mappings and apply naming and design rules (NDR).

So far this tool has been invaluable - in a matter of minutes it has been able to find significant errors in EDXL, PESC and EML schemas that have gone unnoticed in some cases for years. Conversely - internally - it has been able to validate NIEM conformance for schemas faster and more consistently than possible manually.

You will probably have to wait till next week now to get your hands on this - as the xslt is ready - but we're still making java/eclipse changes for the new build.

The potential that you noted though -to also review mapping logic - I definately see would be something scriptable - combined with packing feedback that can then be manually inspected - as we're doing in CAM now - combining xslt with manual review.

Back to UID couplets. The intent is that these will be context specific - driven by XPath of use of a node within the structure. Now of course - the inferencer when finding the same node in a different location, or in difference schema - may assume that the same rules may apply - but they do not have to - since each will be a unique UID. Associated relationships are something I'd not factored in for the first cut at this - but obviously we can also add those linkages (those are easier to manage in a registry rather than flat XML files!).

Simpler may be to just extend from couplets out to triplets, etc. The intent here is to start with simple, and then expand based on needs as we get the initial part working.

-------- Original Message --------
Subject: RE: [set] Groups - A Discussion on Dale Moberg's comments
(DaleMoberg.pdf) uploaded
From: "Moberg Dale" <dmoberg@axway.com>
Date: Wed, May 20, 2009 9:34 am
To: <asuman@srdc.metu.edu.tr>, <set@lists.oasis-open.org>

Comment 1 in the draft was not really a comment but just a review statement indicating that SET's harmonized ontology made use of ideas found in CCTS and in the library. So let us move on.

Comment 2 is again mainly a review statement but contains a comment indicating that I would like to understand better how David Webber's use of couplets can be leveraged within SET. If we reason that item1 = uid1 and item2 = uid1, then item1 = item2, it seems to me that our reasoning is grounded in transitivity of an equivalence relation, and so is semantic, and not lexical. David does say that context is involved in BIEs built from the uid labeled CCs, and he needs to explain a bit more (to me at least) how that impacts his use of the couplets.

However, the above suggestion is a very specialized case of a more general concern about deductive power and descriptive comprehensiveness of the CCTS and supplementary OWL DL assertions. That is found in comment 3, and that is my main worry about the project so far.

Let me say, however, I think that already the SET documents reveal that we can find a number of rules that could function as constraints on a correct mapping. It would, I think, be possible to use these rules to detect semantic misalignment in a proposed map, and that in itself could be a quite useful thing to discover in a map checker module.

In other words, my reservations are more on the automatic map generation ambition of the project. More reduced but important goals seem to be achievable so far.

Comment 4 says that pellet has out of memory errors. I have encountered those in both Protégé 4 and 3.4 environments. I think I made a great deal of progress by editing the protégé.lax configuration file. (I am just loading your owl files into the interactive environment. Running the project using ant ran into some issues, and the debug in eclipse took me to classes lacking source and I ran out of time to see what was really going on :-)! )
Pellet is maybe a bit slower but it does have SWRL support (restricted to some level of DL power and certainly not a full FOL or HOL reasoner.)

# LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.MAX
# -------------------------------------
# maximum heap size

lax.nl.java.option.java.heap.size.max=800000000

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

set message