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

 


Help: OASIS Mailing Lists Help | MarkMail Help

set message

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


Subject: RE: [set] Groups - A Discussion on Dale Moberg's comments (DaleMoberg.pdf) uploaded


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




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