Checking/Evaluating a KB wrt. some Design Rules

  KR model
   

Use the SPARQL endpoint at to check your file at
by this file into this endpoint.      

all objects
        from this endpoint

Evaluated KB global quality: ? %     (given the options currently selected in all sections;
  displayed when the KB is loaded and analyzed; multiplication of the KB qualities according to each section)  

Current level for explanation need:  3 ("interface unknown but RDF+OWL known")     [–]    [+]


I.1. About Object Connectedness
CN: number of satisfying objects   CN–: list of faulty objects C%: connectedness ratio		 Quality level:
From objects
of these classes
 

To objects with
these constraints

 Via relations
of these types
  
Other constraints
  

Below is a manually updatable
(generated from the above menus) 

   in  

     


I.2.  About Mandatory Basic Relations From Objects in the KB (i.e. from each object to at-least-one/no other object; this interface too requires that the tested KB/dataset includes an imports statement for importing the Sub ontology) Quality level:
 
1. From Any Object
rdf:type relation

2. From Any Type
formal definition formal definition via equivalentClass, subClassOf or subPropertyOf    
informal definition informal definition (rdfs:isDefinedBy)
relations expressing Ontoclean-like properties (inferred or not) relations expressing Ontoclean-like properties
      (regarding Identity, Unity, Rigidity and Dependency; cf. the Sub ontology)  

3. From Any Statement 3. From Any Statement, e.g. from any named graph or instance of rdf:Statement  

     3.1. From Any Statement, For Contextualization Purposes
     relations expressing spatial, temporal, authorship/provenance and modal contexts

     3.2. From Any Belief, For Knowledge Sharing Or Argumentation Purposes

relation to one other belief relation to at least one other belief, using one of the following relation types
(or a subtype of one of them):
  • generalization_adding_information, specialization_adding_information or
    instantiation, or
  • logic-argument (e.g. formal-or-informal_proof or
    implied_logic-argument_that_is_not_a_formal-or-informal_proof), or
  • logic-objection (logic-argument implying the negation of the source phrase),
    or preferably
  • corrective_statement (corrective_generalization, corrective_specialization,
    corrective_exclusion or correction_via_an_alternative),
    with the added constraint that these corrective relations must be supported by
    logic-argument relations (and hence that an inference engine may automatically
    decide whether a statement is
    Successfully-supported_and_uncontradicted-or-unsuccessfully-contradicted).

4. Your own conventions:              


Constraint in SHACL   in OWL+Cstr           Query in SPARQL


I.3.  About Mandatory Relations wrt. Upper Ontologies


I.4.  About Mandatory Metadata


    II. About URIs and Labels
Quality level: 

II. About URIs and Labels, in general
URIs dereferencable to an RDF document any URI should be dereferencable into an RDF document
human-readable URIs or labels If an URI is not human-readable,
      at least one human-readable rdfs:label should be associated to it
      [not yet checked]


2. About "Names" (→ Naming Conventions) for Interoperability Between
    RDF and Other formalisms    


Unlike most other formal models, RDF proposes the use of IRIs for object identifiers,
and labels for associating informal terms to objects.
Hence, the lexical conventions of most other KRLs (knowledge representation languages)
and in programming languages – do not directly apply to RDF identifiers and labels.
In other words, this page is NOT about "complete URLs" nor about most "RDF labels".
However, these lexical conventions can be adapted (and extended) to RDF by considering
that in RDF a "name" refers to both of the following notions, i.e. generalises them
(this generalization is necessary 1. to formulate for RDF datasets some lexical conventions
similar to those for datasets in other KRLs, and 2. to enable a formulation of these
conventions in a way that is simple and flexible to follow: each convention specifies that,
for each object, "at least one" of its names - from its IRIs or its labels - must comply
with certain constraints, but only one needs to):
  • A "formal identifier within a dataset", a term that uniquely identifies an
    object within a particular dataset. In some cases, an object identifier is an URL
    (e.g. http://www.domainName.com/datasetName#objectIdentifier or
            http://www.domainName.com/datasetName/objectIdentifier) composed of
    1. a base part which identifies the dataset
        (e.g. http://www.domainName.com/datasetName#objectIdentifier) and
    2. an "object identifying part" (e.g. #objectIdentifier).
    In this case, what is here called "name" is the object identifying part (e.g.
    objectIdentifier). In cases where an object identifier does not have such two parts,
    what is here called "name" is the whole object identifier.
  • A "formal or semi-formal label", i.e. a particular object label (→ rdfs:label)
    which – when all the recorded formal identifiers of the object are not human
    understandable (e.g. URNs) – is meant to be usable as a (formal or semi-formal)
    term for the object when exporting the dataset in a way that is human readable and
    using a particular KRL different from RDF.
    To enable such an export, the formal or semi-formal label must respect the syntax of
    a term in the target KRL. Most KRLs (that do not solely accept IRIs for terms) share
    similar syntax for their identifiers. To enable the above cited kind of exports in
    many KRLs, the formal or semi-formal labels should follow the shared syntax of
    these KRLs. More generally but for the same purpose, it is a good convention to make
    these particular labels follow a very common and simple syntax, i.e. not to use
    characters other than a-zA-Z0-9-_ (hence no accentuated characters nor any space).
    In many KRLs, object identifiers (i.e. formal terms) or object informal names (i.e.
    semi-formal or informal terms) are both called "names", hence the terminology used here.
    A "formal term" refers to only one object, i.e. it has only one meaning.
    A "semi-formal or informal term" is not an object identifier: like most words, it has
    many meanings: it refers to many objects. A semi-formal term respect the syntax of a
    KRL, an informal term does not.
2.1. In General
any object should have at least one name that does not use
      characters other than a-zA-Z0-9-_
for any object, at least 1 name that is not a shortName i) any name without the annotation property sub:shortName can be assumed to be
         explanatory enough for a person not to have to seek a definition of the object for
         understanding its meaning,
      ii) any object should have at least one name that is not a shortName

2.2. About Names for Individuals/Classes/Properties
any individual should have at least one name with an initial in uppercase
any relation type should have at least one name with an initial in lowercase
for any subtype of Class, at least 1 name with a reserved prefix or suffix any subtype of Class should have at least one name with a prefix or suffix
      making explicit that the type is subtype of Class (for checking purposes,
      the default regular expression entails that the name ends by
      "_type", "Type", "_class", "Class", "_property" or "Property")

2.3. About Names for Particular Classes     [not yet checked]
only a class for a collection may have a name in the plural
any class that is not a type of Attribute should have at least
      1 name that is a nominal phrase
only a type of Process (Action) may have a name based on a verb
names based on adjectives or adverbs are for attributes only a type of Attribute may have a name based on an adjective or adverb,
      and only if it has a definition based on a measure wrt. a unit

3. Your own conventions:              


Constraint in SHACL   in OWL+Cstr           Query in SPARQL