Giter Site home page Giter Site logo

international-data-spaces-association / informationmodel Goto Github PK

View Code? Open in Web Editor NEW
62.0 19.0 35.0 98.08 MB

The Information Model of the International Data Spaces implements the IDS reference architecture as an extensible, machine readable and technology independent data model.

License: Apache License 2.0

Shell 82.86% Makefile 6.04% Perl 11.10%
ontology rdf owl semantic-web industrial-data-space linked-data

informationmodel's Introduction

The International Data Spaces (IDS) Information Model

The Information Model is an RDFS/OWL-ontology covering the fundamental concepts of the International Data Spaces (IDS), i.e. the types of digital contents that are exchanged by participants by means of the IDS infrastructure components. The ontology and its documentation are published at https://w3id.org/idsa/core. The model development is led by the Fraunhofer Institutes for Applied Information Technology FIT and Intelligent Analysis and Information Systems IAIS with support by members of the International Data Spaces Association in the context of the Information Model sub-working group (SWG4). The group is chaired by Christoph Lange (Fraunhofer FIT) and Sebastian Tramp (eccenca GmbH).

The model development is based on GitHub, following a defined branching model. Contributions and community feedback are maintained via the GitHub ticketing system. The release process is aligned with the International Data Spaces Association architecture working group meetings, i.e. there are roughly 2 releases scheduled per year with intermediary updates to the development branch. The current release version is 4.1.0, with the latest revision 4.1.0. The Information Model and associated resources published on GitHub are available under the Apache License 2.0.

Authors and contributors

The Information Model was originally created by

  • Jaroslav Pullmann, Fraunhofer FIT now with Stardog Union – succeeded by Dr. Christoph Lange (current co-chair of the information model sub-working group)
  • Dr. Christian Mader, Fraunhofer IAIS and
  • Dr. Sebastian Tramp, eccenca GmbH (current co-chair of the information model sub-working group)

with significant contributions, comments and support by (in alphabetical order):

Likewise, the authors would like to thank numerous colleagues at Fraunhofer, active participants of the International Data Spaces Association, the members of the W3C Dataset Exchange Group and Data Market Austria for illuminating conversations and support in shaping the Information Model.

Directory layout

There are following top-level files and directories:

  • codes: Code lists of enumerated literal values and unique, singleton concept instances. Code lists are the preferred way to encode and reference re-usable instances of a homogeneous value range.
  • docs: Documentation of the latest release of the Information Model and its classes.
  • examples: Example instances providing a guidance on recommended model usage and best practices.
  • images: Figures supporting the understanding and documentation of the Information Model
  • metamodel: Utility models related to annotation and processing of model concepts.
  • model: Core model split into sub-model directories each serving a particular modeling aspect.
  • references: Versioned sources of relevant 3rd party models used as a reference (informative or effective, i.e. via concept import)
  • taxonomies: Hierarchical arrangement of concepts (classes) extending a base concept defined by the core model.
  • testing: Test resources (e.g. RDFUnit) used by tools and the build process to ensure the syntactic validity and semantic consistence of the Information Model
  • utils : Utility scripts used for Information Model development and testing
  • views: Individual tailored views defined upon the overall model for a particular purpose, e.g. the selection of Glossary terms
  • Ontology.ttl: Top-level metadata of the Information Model.

Related resources

Additional resources are provided:

  • Latest information about IDS and all related resources: The IDS-G

  • Releases are provided in this GitHub repository

  • Overview on IDS Messages, descriptions and attribute explanations: Message Overview

  • Java representation of the Information Model, a mapping to a POJO domain model with no reference to graph or ontology constructs. Instances of the Information Model might such conveniently by created, validated and (de)serialized in a strongly-typed way using any common development environment without requiring in-depth knowledge of RDF and related Semantic Web standards. The Java Information Model is provided as a single JAR library via the Maven Repository operated by Fraunhofer IAIS; cf. the documentation:

<repositories>
    <repository>
        <id>snapshots</id>
        <name>maven-snapshots</name>
        <url>https://maven.iais.fraunhofer.de/artifactory/eis-ids-public</url>
    </repository>
</repositories>

The dependency to the Java representation is as follows (replace ${infomodel.version} with the latest version):

<dependency>
    <groupId>de.fraunhofer.iais.eis.ids.infomodel</groupId>
    <artifactId>java</artifactId>
    <version>${infomodel.version}</version>
</dependency>

For automated validation of the Information Model POJOs (via the builder classes) you can include:

<dependency>
    <groupId>de.fraunhofer.iais.eis.ids.infomodel</groupId>
    <artifactId>validation-serialization-provider</artifactId>
    <version>${infomodel.version}</version>
</dependency>

For members of the International Data Spaces Association only:

  • Working document, explaining the usage of the Information Model for data exchanges in the IDS.

Citation

If you use the Information Model in scientific work, please consider citing:

@inproceedings{BaderEtAl:IDS-InfoModel20,
  author   = {Sebastian Bader and Jaroslav Pullmann and Christian Mader and Sebastian Tramp and Christoph Quix and Andreas W. M{\"u}ller and Haydar Aky{\"u}rek and Matthias B{\"o}ckmann and Benedikt T. Imbusch and Johannes Lipp and Sandra Geisler and Christoph Lange},
  title    = {The International Data Spaces Information Model -- An Ontology for Sovereign Exchange of Digital Content},
  doi      = {10.1007/978-3-030-62466-8_12},
  crossref = {iswc2020},
  pages    = {176--192},
  year     = 2020,
}

@Proceedings{iswc2020,
  editor          = {Jeff Z. Pan and Valentina Tamma and Claudia d’Amato and Krzysztof Janowicz and Bo Fu and Axel Polleres and Oshani Seneviratne and Lalana Kagal},
  eventdate       = {2020-11-02/2020-11-06},
  eventtitle      = {19\textsuperscript{th} International Semantic Web Conference},
  eventtitleaddon = {ISWC},
  isbn            = {978-3-030-62465-1},
  number          = {12507},
  publisher       = {Springer Verlag},
  address         = {Cham, Switzerland},
  series          = {Lecture Notes in Computer Science},
  booktitle       = {The Semantic Web},
  title           = {The Semantic Web},
  venue           = {Athens, Greece},
  year            = {2020},
}

informationmodel's People

Contributors

aliariff avatar bearn01d avatar changqin26 avatar clange avatar cmader avatar fraunhoferiais-ids avatar hosseinzadeha avatar johanneslipp avatar lcomet avatar liam-tirpitz avatar maboeckmann avatar mkollenstart avatar muucha avatar newinnovations avatar phochmann avatar pnlinden avatar sebbader avatar seebi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

informationmodel's Issues

Find or create modularization ontology

Identify an existing ontology (or create a new one) that allows to introduce additional structure to owl ontologies. For example, it should be possible to assign classes to modules so that a more high-level view of an ontology can be communicated.

Broker query capabilities specification

A Broker needs to publish the query languages it "understands" when receiving BrokerQueryMessages. Furthermore, brokers need a way to make the client know how to formulate his queries because each broker is free to its own data model for storing connector registrations internally. Options are to

  • publish the internal schema
  • prescribe a schema
  • define a special broker query language

What solution should we go for?

Establish a continuous integration process

Currently the Information Model is only insufficiently tested, there is no automated provisioning process. Decide upon a CI methodology and technology. Implement naming, location and processing conventions (e.g. ./test/<Entity>.shacl test files, turn custom validation rules (idsm:validation) into SHACL expressions etc.

Rediscuss (Broker) Messages for managing registry entries

At the moment, message types in the Information Model are intentionally expressed very generically. For instance, for handling connector lifecylces, we have ConnectorAvailableMessage, ConnectorUnavailableMessage, ConnectorTemporarilyUnavailableMessage, ConnectorConfigurationChangeMessage.
These messages are intended to express, what happened in the IDS ecosystem and not what a specific system (like, e.g., a Broker) should do. This gives us the freedom to decouple the information model from concrete component functionality.
Example: If a Broker receives a ConnectorAvailableMessage, it interprets it in a way that there is a new connector being put into operation, that was not previously there, hence adding it to a registry. In a similar way, a Broker retrieving ConnectorTemporarilyUnavailableMessage, may decide to exclude the unavailble Broker from any search results. However, a clearing house or any other kind of trusted third party will consume ConnectorTemporarilyUnavailableMessage to measure connector downtime so that communication partners may find out about contractual service level agreement violations.
For a future Participant Registry that holds information about IDS Participants, similar message types are needed. It should be discussed, how these fit into this concept and actual message types should be defined.

Make relation of IDS' customization of ODRL (left operands, operators, …) to the original ODRL more explicit

So far, our specializations of ODRL (e.g. https://github.com/IndustrialDataSpace/InformationModel/blob/fb494ba2513f6799262751abe2d44b57507090b3/codes/LeftOperand.ttl#L46) are linked very loosely to the original terms of ODRL, by the pretty much meaningless rdfs:seeAlso. Saying owl:sameAs would probably be too strong (meaning that all statements that hold true of the IDS term also hold true of the ODRL counterpart and vice versa), but all these ODRL terms also have a SKOS semantics. Thus, we could say, e.g., ids:purpose skos:broader odrl:purpose.

Support for defining custom policy constraint predicates (i.e. leftOperand)

Currently the predicates used in policy constraints (leftOperand) are defined informally by the ODRL CG, for example odrl:language. The predicate semantics, requirements on interpretation (e.g. which internal context model is needed to decide upon), compatible operators and eligible value range (i.e. types of values in rightOperand) should be defined in an unambiguous and possibly formal, machine-interpretable manner.

Add ParticipantNotificationMessage for consistency in Messages

Participant related NotificiationMessages (in the Messages.ttl taxonomy) do not have a proper superclass like the ConnectorNotificationMessage and ResourceNotificationMessage.
Add class for consistency.

  • Add ParticipantNotificationMessage as superclass to all Participant_____Messages
  • Make ParticipantNotificationMessage subclass of NotificationMessage

Support MediaType annotation in Java library

ids:MediaType is a super-class of media types, either defined by IANA (ids:IANAMediaType) or any custom authority (not further typed). Since code list instances are mapped to Java enums, based on their class two disjoint enums were consequently created, omitting benefits of having a single Media Type enum (assertability, unique values, no duplicates). Please check the design of the Media type concept and its mapping to Java.

Extract and improve "helper" ontologies

Extract "helper" ontologies for API generation (covering additional validation and documentation properties and classes) into separate files. Improve property definitions (e.g., valid:relationType "@OneToMany" or valid:constraint "@NotNull") in terms of structure and documentation.

InfoModell into Certification Criteria

We need to add requirements for IM support (which versions, which features, mandatory and optional attributes, etc.) into the IDS Ready certification list.

Literal values conventions

Make the assumptions on and handling of literals explicit. Document where "simple literals" are fine or further annotation by datatype and language tag is required (e.g. because of transformation into Java representations).

language, temporal, spatial

You define language, temporal and spatial as sub-props of DCT, but I can't see how are the respective classes richer than DCT. Why not use DCT directly?

Eg here's a discrepancy:

ids_da:coversLanguage rdfs:subPropertyOf dct:language;
    rdfs:range ids_lang:Language;
    rdfs:comment "States the language that is used in the DataAsset."@en.

On the other hand,

dct:language rdfs:range dct:LinguisticSystem ;

By RDFS reasoning from DCT and IDS_DA, every object of ids_da:coversLanguage will get type dct:LinguisticSystem. But there's no connection between ids_lang:Language and dct:LinguisticSystem declared by IDS, so only the used languages will get this type. Is this really intended?

(BTW, I think the name ids_da:coversLanguage is not very accurate. A dictionary covers a language; a resource that merely uses a language cannot be said to cover it.)

Cheers!

Migrate fully from DCMI Terms to DCAT where possible

Some our terms are defined as refinements of DCMI Terms, others of DCAT. However, much of DCAT is also defined by refining DCMI Terms. Thus, wherever and whenever information model terms refer to DCMI Terms but there is actually a compatible or more specific term in DCAT, the information model should rely on DCAT instead of DCMI Terms.

Support for defining custom policy constraint values (i.e. rightOperand)

Values (rightOperand)s are probably the most variant / custom parts of policy constraints. Given a closed-value and predefined range (boolean, ISO 4217 currency code etc.) the interpretation and validation constraints are sufficiently defined by the leftOperand. In contrast, open-valued ranges require ad-hoc definition of validity and interpretation. For example a context-sensitive rule may state a "permission to access <disaster_recovery_plan> when <ongoing_event> in (MassEvent1, MassEvent2, MassEvent3 )". There should be a reference to or inline definition of such constraint values, e.g. as agreed upon in course of the policy negotiation.

Provide UsagePolicyTemplateIdentifiers into the InfoModel

The Usage Policy Language provides several templates. IDS participants need to be enabled to refer to these templates. Therefore, unique identifiers should be defined by Information Model. Probably as part of the /codes/ directory?

SecurityProfiles and extendedGuarantee attributes

SecurityProfiles are intended as a shortcut and alignment regarding the certification profiles. However, the result is a logical inconsistency if e.g. idsc:BASE_CONNECTOR_SECURITY_PROFILE ids:securityGuarantee idsc:AUDIT_LOCAL_LOGGING but a connector specifies also:
<> ids:extendedGuarantee idsc:AUDIT_REMOTE_TRACING .

Now ids:securityGuarantee idsc:AUDIT_LOCAL_LOGGING should be beaten by ids:extendedGuarantee idsc:AUDIT_REMOTE_TRACING. That's not how RDF works.

Option 1: Remove the SecurityProfiles completely and stay with the more detailed ids:SecurityGuarantee. Con: Increases the size of the DAT.

Option 2: ??

Achieve compatibility with DCAT 2

The W3C Data Exchange Working Group (https://www.w3.org/2017/dxwg/) is working on DCAT 2. DCAT 2 made it to the Candidate Recommendation stage on 3 Oct 2019 (https://www.w3.org/TR/vocab-dcat-2/). Considering the

we should make sure that our information model is compatible with DCAT 2.

Some relevant features of DCAT 2 include:

  • more expressive description of temporal and spatial extent of a data resource (e.g., DCAT itself now implements what we modelled on our own using ids:temporalCoverage and ids:begin etc.
  • vocabulary to talk about relations of a resource to another resource (e.g. its original version)
  • a way to talk about the data quality of a resource, in terms of the W3C Data Quality Vocabulary

Extend RejectionReason codes

Extend value space for RejectionReason. Review related work (e.g., HTTP error status codes) and check if they can be reused.

Duplication of Hosts for Endpoints in SelfDescription

In connector self-descriptions with a lot of dynamic endpoints, e.g. when mapping a REST server to the Information Model, the endpointHost property is added to all endpoints.

This makes the self-description unnecessary verbose.

My suggestion would be to reference the endpointHost property of Endpoints by url, linking to the hosts defined at the connector level.

release v1.0.0

  • build artifacts
  • validate build artifact in Corporate Memory
  • count triples
  • announce ids prefix at prefix.cc
  • upload artifact to github
  • fix namespace resolution at permaid @cmader
  • announce ids vocab at LOV @jpullmann

Version identifier for message payload

In the message header, we need a way to specify an optional version identifier of the payload information. That version identifier should indicate the version of the description of the information in the payload.
The reationale is that we need some way to refer to information that was once sent to some other system on the ids (e.g., a broker) but which is now out of date and needs to be updated. This is especially needed if, e.g., a connector wants to update its self description on a broker via a patch ("diff") document, both the connector and the broker need to refer to the same version of the existing description in order to create and to apply the patch.
A connector config update message therefore needs to refer to (i) the old version identifier and (ii) the version that the information should have after successful application of the patch.

Provide a full dereferencable human-friendly documentation

There seem to be a couple of issues:

(1)
The Information Model is not (yet?) deployed on: https://schema.industrialdataspace.org/.

But there exist an (old?) one on: http://ids.semantic-interoperability.org/

(2)
The IRI of the Information Model should be probably extended with the hashtag symbol #:
https://schema.industrialdataspace.org/#

(3)
The existing deployment on http://ids.semantic-interoperability.org/ could be a bit improved:

(3a) Resource names show up twice in the IRI:
http://ids.semantic-interoperability.org/#dataAsset/DataAsset

(3b) A resource reference provided for example in the Class List: http://ids.semantic-interoperability.org/#classes is not identical with the actual resource IRI:

Resource Reference IRI in the Class List:
http://ids.semantic-interoperability.org/#dataAsset/DataAsset <- hashtag with old IRI
Actual IRI:https://schema.industrialdataspace.org/dataAsset/DataAsset <- no hashtag

Security Token support for Message class

According to the envisioned IDS secure communication scenario, there are 2 different security tokens involved:
(1) an identity token that is retrieved from the identity provider in the connector onboard phase and presented in each subsequent infrastructure component interaction,
(2) an authorization token that can optionally be issued by a (data providing) connector to another (data consuming) connector in order to give different requesting connectors different access rights. Issuing authorization tokens may be done by proprietary components internal to the (data providing) connector.

As a consequence, I propose these changes:
(1) rename the authenticationToken property of the Message class to identityToken
(2) add a new property authorizationToken to the Message class
(3) rename the class AuthenticationToken to SecurityToken which will be the range of the properies in (1) and (2). It should hold general informaiton and the value of the token.

Does this sound ok?

Fine-grained definition on reliabilites for usage enforcement

The instances of ids:Action need a distinction in provider- and consumer-side. For instance:

idsc_action:anonymizeByProvider a ids:Action .
idsc_action:anonymizeByProvider dcterms:isPartOf idsc_action:anonymize .

idsc_action:anonymizeByConsumer a ids:Action .
idsc_action:anonymizeByConsumer dcterms:isPartOf idsc_action:anonymize .

idsc_action:anonymize dcterms:isPartOf odrl:anonymize .

My problem with this approach is the modeling at instance-level (ABox) instead of TBox. An alternative could be something like an refinement-based approach with LeftOperands (also ugly):
[ ] a ids:Action ;
odrl:includedIn idsc_action:anonymize ;
ids:actionRefinement [
a ids:Constraint ;
ids:leftOperand idsc_constraint:whichSide ;
ids:operator ids:eq ;
ids:rightOperand idsc_constraint:clientSide ;
] .

Arbitrary data in the IM

At /model/participant/references/foaf-20140412.ttl I found a disturbing line that makes no sense to me:
rdfs:Class a owl:Class .
As far as I know (and from https://www.w3.org/2002/07/owl#), the owl:Class is a rdfs:Class and a subclass of rdfs:Class, but not the other way round. Also makes no sense if you think about it. That also implies, that foaf:Agent has an unneccesary rdf:type relation to rdfs:Class, because foaf:Agent is also a owl:Class.
It makes me wonder, if that reference document is trustworthy at all.

Edit:
At http://xmlns.com/foaf/spec/20140114.rdf you can find the current definition of foaf:Agent. There is no direct inheritance from rdfs:Class as you can see:

<rdfs:Class rdf:about="http://xmlns.com/foaf/0.1/Agent" vs:term_status="stable" rdfs:label="Agent" rdfs:comment="An agent (eg. person, group, software or physical artifact).">
  <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Class"/>
  <owl:equivalentClass rdf:resource="http://purl.org/dc/terms/Agent"/>
</rdfs:Class>

ids_da:licenseReference is not really compatible with dct:license

What is the rationale of separating these two:

  • ids_da:licenseDocument "License of the DataAsset. Refers to common standard licenses used in the IDS."
  • ids_da:licenseReference "References a license document that is publicly available on the Web."

I think this separation of "common standard licenses" vs "license document that is publicly available" is non-orthogonal and not always clear. Eg if an IDS standard license becomes popular and adopted by CC, does that mean all relations pointing to it need to be changed?

Is there a background reference explaining the rationale for separation?

In any case, here's a formal objection:

ids_da:licenseReference rdfs:subPropertyOf dct:license;
  a owl:ObjectProperty; rdfs:range xsd:anyURI;

But xsd:anyURI is a literal (and I've never understood the utility of this literal in RDF, which unlike XSD, makes URLs first-class citizens). Just a few lines later you have

ids_da:origin a owl:DatatypeProperty;  rdfs:range xsd:anyURI;

Furthermore, dct:license is an object property:

dct:license rdfs:range dct:LicenseDocument ;

It's not a good idea to make a data property sub-property of an object property.

Decide upon a formal modelling and differentiation of content instances (artefacts)

According to a "traditional" interpretation instances of a resource representation (artefcts) "share the same intellectual content in different physical formats" [1]. In contrast, there are frequent examples of resources materialized as lose collection of files or series of files ordered according to particular content dimension (day, area etc.), example TrainDelays_Jan_2019.csv, TrainDelays_Feb_2019. Individual file are at most distinguished by semi-structured file names or textual descriptions. Inspired by Data Cube Vocabulary descriptive parameters were used to formally express the distinguishing dimensions, see example DATA2. This benefits from re-using the API Parameters concept. On the contrary, descriptive predicates like dct:spatial or dct:temporalexist, but are currently applied to the abstract resource only. Evaluate these and alternative approaches to model and semantically differentiate resource instances.

Redesign of the ids:Language class / properties using more accurate ontologies.

Problem:

The current implementation of ids:Language, especially the language instances, lack references to existing, standardized language vocabularies and language code lists. dcterms is inaccurate.

Suggestion:

Redesign ids:Language using the Lingvoj vocabulary. Lingvoj further specifies dcterms:language and dcterms:LinguisticSystem and also contains instances of languages with references to standardized language codes.

Example of an instance

lexvo:deu
    a   schema:Language, lingvo:Lingvo ;
    rdfs:label   "German" ; 
    lvont:iso639P1Code   "de" ;
    owl:sameAs  loc1:de ; 
    lvont:iso639P2BCode   "ger" ;
    owl:sameAs  loc2:ger ;
    lvont:iso639P2TCode   "deu" ;
    lvont:iso639P3Code   "deu" ; 
    owl:sameAs <http://dbpedia.org/resource/ISO_639:deu> ;
    rdfs:seeAlso <https://www.freebase.com/authority/iso/639_3/deu> ;
    prov:hadPrimarySource  <http://www-01.sil.org/iso639-3/documentation.asp?id=deu> ;
    lingvo:supportingResource  <http://www.language-archives.org/language/deu> ; 
    lingvo:supportingResource  <http://eurovoc.europa.eu/drupal/?q=de> ;
    lingvo:supportingResource  <http://www.eionet.europa.eu/gemet/index_html?langcode=de> ;
    lingvo:supportingResource  <http://de.wikipedia.org> ;                                                  
    lingvo:supportingResource  <http://en.wiktionary.org/wiki/Category:German_language> ;    
    lingvo:supportingResource  <http://www.freelang.net/dictionary/german.php> ; 
    lingvo:supportingResource  <http://www.omniglot.com/writing/german.htm> ; 
    lingvo:supportingResource  <http://www.lexilogos.com/english/german_dictionary> ; 
    lingvo:supportingResource  <http://www.lexicool.com/dictionaries_german.asp> ; 
    foaf:isPrimaryTopicOf   <http://www.lingvoj.org/languages/tag-de.html> .    

Relation between Connector and InfrastructureComponents

Currently:
Connector --|> InfrastructureComponent --|> ManagedEntity
and:
Broker --|> Connector
ClearingHouse --|> InfrastructureComponent
DAPS --|> InfrastructureComponent
IdentityProvider --|> InfrastructureComponent
PARIS --|> InfrastructureComponent
VocabularyHub/VocabularyProvider deprecated

Suggestion:
InfrastructureComponent --|> Connector --|> ManagedEntity
Broker --|> InfrastructureComponent
ClearingHouse --|> InfrastructureComponent
DAPS --|> InfrastructureComponent
IdentityProvider --|> InfrastructureComponent
PARIS --|> InfrastructureComponent
VocabularyProvider --|> ManagedEntity

ids_da:version is incompatible with dct:hasVersion

https://github.com/IndustrialDataSpace/InformationModel/blob/develop/modules/dataAsset/DataAsset.ttl#L49

ids_da:version rdfs:subPropertyOf dct:hasVersion;
  rdfs:range xsd:string;
  rdfs:comment "Version identifier of the InfrastructureComponent."@en.

Many people make the mistake that dct:hasVersion is some sort of version number. It is not:

dct:hasVersion
    rdfs:comment "A related resource that is a version, edition, or adaptation of the described resource."@en ;
    rdfs:subPropertyOf dc:relation, dct:relation ;

In fact it's inverse of dct:isVersionOf (even though not declared in dct).

So, remove that rdfs:subPropertyOf.

Missing interface extends in Java library

Java Lib generation: It seems that if an IDS class A is a subclass of some superclasses B and C where B is in the IDS namespace and C is not, then the corresponding java interface that is generated for A is does not extend B.

Enhance description property for external vocabs

ids:Described (super class of ids:Resource) has the property ids:description. As far as I understand it, that's the best entry point for any explanation on the actual content of a resource.
However, ids:description has range PlainLiteral. In case I want to supply structured information (e.g. using other RDF ontologies), I am stuck here.
In case we do not have a better construct to append such vocabs I suggest to change the range to rdf:Resource and provide best practices how to add both textual and machine-readable descriptions.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.