Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 26 18:19

    sotty on develop

    Improve API documentation (vers… [OMG] Clone and freeze current … Fix typo in config.xml and 2 more (compare)

  • Feb 23 03:47

    sotty on develop

    candidate release 9.0.9 [skip ci] update develop branch… (compare)

  • Feb 23 03:47

    sotty on main

    [skip ci] update develop branch… Ensure consistent generation of… New branch for the 20210201 OMG… and 9 more (compare)

  • Feb 22 15:10

    sotty on main

    (compare)

  • Feb 22 15:04

    sotty on main

    (compare)

  • Feb 22 15:00

    sotty on develop

    [#277629] Implement getComposit… [#297324] Add endpoint(s) to re… candidate release 9.0.4 and 19 more (compare)

  • Feb 14 00:31

    ElisaKendall on 20210201

    Slight revision to the individu… (compare)

  • Jan 31 02:16

    ElisaKendall on 20210201

    Renamed file api4kp-kp-inst to … (compare)

  • Jan 31 01:36

    ElisaKendall on 20210201

    Cleaned up registry header cont… (compare)

  • Jan 30 22:55

    ElisaKendall on 20210201

    Cleaned up header and prefix de… (compare)

  • Jan 30 22:41

    ElisaKendall on 20210201

    Initial pass to clean up header… (compare)

  • Jan 30 22:01

    ElisaKendall on 20210201

    Revised header information in t… (compare)

  • Jan 29 22:45

    ElisaKendall on 20210201

    New branch for the 20210201 OMG… (compare)

  • Jan 11 15:26

    sotty on develop

    Update azure-pipelines-develop.… Remove duplicate DITA language … candidate release 9.0.0 and 8 more (compare)

  • Dec 12 2020 00:05

    sotty on develop

    [#402077] fix minor documentati… Add FHIR R4, WSDL, DITA, LwDITA… (compare)

  • Dec 11 2020 18:00

    sotty on develop

    [#402077] refactor getCanonical… (compare)

  • Dec 01 2020 08:01

    sotty on master

    [skip ci] update develop branch… candidate release 8.0.4 [skip ci] update develop branch… and 16 more (compare)

  • Dec 01 2020 07:53

    sotty on develop

    candidate release 8.0.4 [skip ci] update develop branch… candidate release 8.0.5 and 16 more (compare)

  • Nov 11 2020 23:32

    ElisaKendall on ontology-updates

    Corrected import IRI for DOL-te… (compare)

  • Oct 15 2020 15:25

    sotty on master

    [skip ci] update develop branch… Ontology work in progress Ontology work in progress and 76 more (compare)

Tara Athan
@greenTara
Just encountered this https://www.w3.org/TR/ldp/ - may be of interest for us.
Tara Athan
@greenTara
Working Session - Elisa, Davide, Tara and Ralph
Tara Athan
@greenTara
There is a github repo for MagicDraw models - https://github.com/API4KBs/md-models
Tara Athan
@greenTara
Resuming dive into KnowledgeResource
We created an alignment with DOL's Native OMS.
We investigated the DOL concepts of Basic and Structured. We are ok with the idea of Basic and Structured forming a disjoint partition.
However, DOL defines StructuredOMS in terms of Structuring Operations, without a clear definition of what is the criterion for an operation to be structuring.
We, however, have a more restrictive approach where Structured things are based on monads.
Since structuring operations can also come from the native languages, there is little control over what these things would be, and they may not fit with the monadic framework.
Therefore we agree to diverge with DOL over what is a StructuredKnowledgeExpression.
Tara Athan
@greenTara
It may be possible to have two levels of structuring operations - a general notion, that includes the DOL concept of structuring, and a more specific notion. e.g. tied to monads.
edit: (at least two levels)
Lonnie VanZandt
@lonniev
Requirements from the RFP for API4KP.png
This figure shows the requirements on the API from its RFP. Oversimplifying things, if one assured that there was a REST URL for each of the little pink boxes then one could claim that their proposed API met the interface requirements.
Given the requirements, we can specify an interface (a RESTful PIM one as required by the RFP) and then indicate which requirements are satisfied and which are not and indicate which API services satisfy a requirement and which are not required.
Tara Athan
@greenTara
Working Session
Ralph Schäfermeier
@RalphBln
I haven't received a webex invitation?
Tara Athan
@greenTara
We discussed "Structure" - we have rejected the DOL definition of structure because it depends on a concept of "structuring operations". But we have to replace it with something. One way to go would be to have a property like "hasStructure" or "hasStructureType" (whichever is more clear, but the idea is that the value is a monadic type like Set or List or ...)
With this in mind, we looked for the levels of the KnowledgeResource hierarchy where this notion makes sense.
Tara Athan
@greenTara
Here is an example process: we have an OWL file sitting on a hard disk (Item). This file gets read into a characater sequence (Manifestation). This character sequence is loaded into a tool (e.g. Protege) which parses it. At this point, the tool can recognize that there are import statements in the onology (or not) and decide whether the Expression is structured or not. Before that point, it was not possible to make that determination. Finally, the tool carries out the importation resolution and forms an internal representation of the theory - this is the Asset level, which has a syntax-free character to it. So the Asset does not inherit the structural character from the expression. In particular, the same Asset could be "expressed" as a structured expression (like the one it was derived from) or as a basic (unstructured) expression containing all the axioms from the importation resolution.
Conclusion: the only level where "structured" makes sense is at the Expression level.
Tara Athan
@greenTara
Proposal: the following classes would be deleted from the ontology:
Structured
StructuredKnowledgeAsset
StructuredKnowledgeEncoding
StructuredKnowledgeManifestation
StructuredKnowledgeItem
StructuredKnowledgeResource
Basic
BasicKnowledgeAsset
BasicKnowledgeEncoding
BasicKnowledgeManifestation
BasicKnowledgeItem
BasicKnowledgeResource
The removal of the Structured and Basic classes are due to them not being needed as an abstraction of the e.g. "hasStructureType" property because that behavior only applies one place - in StructuredKnowledgeExpression.
Tara Athan
@greenTara
On a related note, we discussed the desirability to continue getting rid of intermediate "conjunction" classes - those classes that only serve to capture the conjunction of some set of higher-level classes and don't have any inherent new behavior. In this case it is accomplished because StructuredKnowledgeExpression would no longer be defined as the conjunction of Structured and KnowledgeExpression, but as a subclass of KnowledgeExpression with a property restriction.
There is another reason to get rid of such classes, other than making the ontology cleaner - they will also make for a better Java API if we carry out a 1-1 (or close to 1-1) conversion of the ontology into Java.
Tara Athan
@greenTara
Before we make these deletions, we should check on the usages of these classes: for next time ...
In a separate discussion, we talked about the possibility of conversion from the ontology to Java and then reverse engineering to IDL.
Could someone else capture the notes on that discussion, please?
Ralph Schäfermeier
@RalphBln
Tools to consider for the OWL → Java translation:
  1. Sapphire (http://www.simondobson.org/softcopy/sapphire-odise11.pdf)
  2. Empire (https://github.com/mhgrove/Empire)
Not all classes from the ontology will actually be part of the public API and have a direct correspondence to a java class or interface. So there would be two different concerns addressed by the ontology: The original concern of modeling the API4KP domain and a related but more technical code (or object model) generation concern.
Tara Athan
@greenTara
Working Session
Tara Athan
@greenTara
KnowledgeResource is Immutable
Tara Athan
@greenTara
We are keeping Structured (and Basic) for now because this may be useful for some other structured things, e.g. StructuredEnvironment, StructuredPlatform?
Tara Athan
@greenTara
There is possibly something questionable about the equivalence class for Basic, as it is based on the absence of a property, and this is very broad.
Tara Athan
@greenTara
We are done with the modifications on Basic and Structured classes.
Ralph Schäfermeier
@RalphBln

There is possibly something questionable about the equivalence class for Basic, as it is based on the absence of a property

OWL operates under the Open Worlds Assumption, though, which means that the absence of any assertions involving this property would have to be made explicit.

Ralph Schäfermeier
@RalphBln
#38 (reasoning not possible due to violation of OWL 2 restrictions): We must either abandon the property chain or the cardinality restriction on usesLanguage in NativeKnowledgeExpression.
Lonnie VanZandt
@lonniev
Not intentionally snubbing you folk: I’m in a conflicting call for INCOSE.
Tara Athan
@greenTara
Note in regard to a side conversation about FRBR Work: here is where OWL talks about ontology series https://www.w3.org/TR/owl2-syntax/#Ontologies
Business Meeting
Tara Athan
@greenTara
We have another working session schedule for 8AM Pacific, 11AM Eastern, 5PM CEST
Ralph Schäfermeier
@RalphBln
Working Session
task for next time: get rid of KnowledgeEncoding
Ralph Schäfermeier
@RalphBln
Working Session
TODO: specify a metamodel for the compositional approach to qualifying operations
Ralph Schäfermeier
@RalphBln
TODO: Review classifiers, rename classifiers to aspects
Ralph Schäfermeier
@RalphBln
TODO (Ralph): Rename "classifier" to "aspect"
TODO (Ralph): Document the entire classifier/aspect business