LWS Authorization issues used in ACLs Give principles access to resources slides: https://hackmd.io/@ericP/Hk1NDnic1g#/1 Tech examples WAC: Simple, interoperable, and RDF-native, but limited to static ACLs and coarse access distinctions. ACP: The most aligned with decentralized data governance — supports policy re-use, linked data, conditions, and delegation.

Stable LWS Locators Identity, Data, and Metadata Portability terms:AAA — Authentication, Authorization, and Accounting Identity provider — manages the subscriber’s primary authentication credentials Storage provider — serves, e.g., HTTP requests for (user's) resources Owner/User — rights to and responsibility for a resource \ provider agreement PortabilityEstablishing identity or resources while using Provider A   that can be used when   the relationship with Provider A has been severed.

The HL7 FHIR/RDF group is standardizing a mechanism to convert CodeableConcepts into (RDF-friendly) URLs. This generalizes a SNOMED and LoINC-specific schema that existed in R4's FHIR/RDF. Look for "a loinc:29463-7 ;" in https://hl7.org/fhir/R4/observation-example.ttl.html . Gaurav's version Hi there! The FHIR RDF group (link) has been In addition, we have been developing a mechanism for automatically converting

Research interest: ☐ [R1] Multi-omics analysis on human genotype to phenotype that includes genomic, transcriptomic, epigenomic, proteomic, protein structures, and biochemical data. ☐ [R2] Automated data analysis of microorganisms including phylogenetic compositions, gene annotations, pathways, and growth conditions. ☑ [R3] Data-driven interdisciplinary studies in public health, environment, agriculture, food, energy, and other fields. ☐ [R4] Facilitating knowledge discovery and biological analysis of knowledge graphs and literature. Technical aspects: ☑ [T1] Data ☐ [T2] Algorithm ☐ [T3] Analysis

Acronym MaCD4Rules Abstract Clinical data is expressed in many hundreds of medical electronic record formats. To encourage interoperability, knowledge portability, and the development of a cross-platform health application ecosystem, many vendors, standard development organizations, and user groups concentrate on developing exchange formats like C-CDA and, more recently, FHIR. Yet, even with such standards, interoperability remains elusive. Some have proposed the use of well-defined clinical logical models and corresponding APIs to help address this challenge. Electronic medical record (EMR) formats are typically designed around highly regularized generic structures which are far from the mental models that clinicians have in their heads in their daily practice. Offering clinicians intuitive models allows them to participate in the production, approval, and long-term evaluation of clinical decision support rules. For instance, asking a clinician to write rules in terms of blood pressures containing both systolic and diastolic components will be generally much more productive than asking them to write rules about a FHIR resource with a resourceType of "Observation" and two components, one with a code of type CodeableConcept containing some Coding concept references for one of many deployed codes for "Systolic blood pressure"... To further complicate matters, resources may vary across versions of FHIR and may be modeled differently within a given version of FHIR. Thus, to support greater portability in health care, any given messaging model ought to be normalized into rules model, a form that can be generally consumed and produced by health applications thus reducing current degrees of freedom. ShexMap may support such normalization by converting local data models into a more representational form that can be readily consumed by knowledge applications. ShexMaps were used in a pilot to migrate patient data from the Department of Defence to the Veteran's Administration. In another effort, in order to enable rules written over a natural object-oriented class hierarchy, clinical data had to migrated to that model. In a recent NIH grant 5-R01-EB030529-02, we annotated the FHIR ShEx schema for Observation with ShExMap Semantic Actions that were mapped to a rules schema. This enabled automatic instance data translation to many different clinical models used by the rules.

PREFIX schema: http://schema.org/ # for backwards compat esp. in JSON-LD PREFIX sdo: https://schema.org/ # Declaring but not using for instance data PREFIX techdoc: sdo: # For using within annotations TODO: create better vocabulary instead of overloading description, text, identifier etc. Add disclaimers in UI where text is from services. PREFIX googledev: https://developers.google.com/search/docs/appearance/structured-data/factcheck# IMPORT <schema.org-shapes.shex>

-- tags: ShExMap -- resources ShExMap

root@pheasant:~ # nmap -sS -P0 porklips.org Starting Nmap 7.40 ( https://nmap.org ) at 2019-08-01 13:31 EDT Nmap scan report for porklips.org (128.52.130.142) Host is up (0.011s latency). rDNS record for 128.52.130.142: mail.porklips.org Not shown: 975 filtered ports PORT STATE SERVICE 22/tcp closed ssh 23/tcp closed telnet

Merges The latest js-api change is present in the CR document The Upgrade to IEEE 754-2019 (#1050) just updates the IEE754 reference to the most recent spec -- doesn't change implementation The rest of the PRs are typographic or for the interpreter, which is not a CR-related product. Issues Published jsapi spec is out of date -- no textual change; related to github pages.

Tracking issues: iovka/shex-java weso/shex-s Apache Jena Goal: common API for invoking basic validation function across all JVM ShEx validators. The input parameters: