UBL / CEFACT Status Re: [set] Groups - A Discussion on Dale Moberg's comments (DaleMoberg.pdf) uploaded

[Stephen Green <stephen.green@documentengineeringservices.com>]

copied from chatroom...

Stephen Green: http://lists.oasis-open.org/archives/ubl/200904/msg00013.html

Stephen Green: http://www.oasis-open.org/committees/download.php/32023/UBL-CommonLibrary-2.0-CCL08BMapping-April0102009.xls

Stephen Green: http://www.oasis-open.org/committees/download.php/32024/TBG17_Submission_UBL_CCL08B.xls

Stephen Green: http://www.oasis-open.org/committees/download.php/32254/UBL-CommonLibrary-2.0-CCL08BMapping.zip

Please change your name from 'anonymous' using the Settings button

anonymous morphed into Steve

Steve: http://www.oasis-open.org/committees/download.php/32253/DRAFT_2009_summary_UNCEFACT_and_UBL_TC_collaboration_2009-04-24%20rev%201_clean.pdf

Steve: latest ubl face 2 face plenary notes confirm ubl agreement to
continue work with cefact
http://lists.oasis-open.org/archives/ubl/200904/msg00044.html and
mention the above links

2009/5/20 David RR Webber (XML) <david@drrw.info>:
> Dale,
> 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.
>
> Thanks, DW
>
> -------- 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
>
> --------------------------------------------------------------------- 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