Re: Glossary for the working group

Fabulous, totally needed. Couple nits inline.

On Nov 19, 2014 5:51 PM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
wrote:
>
> There have been a lot of terms being used in the mailing list but no
definition of these terms.  The working group should try to use terms in a
consistent manner.
>
> I have attached a short glossary of some terms that have been frequently
used in the working group so far plus a several more that are needed to
give these terms meaning.   I also had to disambiguate several terms.  I
also went ahead and added two terms that I think will start to show up
quite soon (decoration and validation).
>
> I tried to tie these terms back to ShEx, SPIN, and OWL constraints
wherever possible and to give examples in several key cases.
>
> Enjoy,
>
> peter
>
> Document:  A container for a sequence of Unicode characters available,
which
> may or not be the accessible via URL dereferencing.
>
> RDF graph: See RDF 1.1 Concepts and Abstract Syntax.  RDF graphs may be
> accessible via one or more URLs by dereferencing the URL and parsing
> the resultant document.

You make reference to validating graphs but we may want to validate
multiple graphs with respect to reach other (feature req from Jeremy
Carroll and others). In the context of validation or type matching on RDF
datasets, we *may* want to distinguish between an RDF database and a subset
of it which is being validated.

> Ontology: Something that provides information about classes and
properties,
> e.g, an RDF graph containing RDFS properties or a normal OWL ontology.  It
> should be possible to transform the ontology into an RDF graph in a
standard
> way.  Ontologies may be accessible via one or more URLs, but it may
require
> more than URL dereferencing and parsing of the resultant document into an
> ontology, for example importing may have to be performed.
>
> Schema: Something that provides a set of constraints that can be applied
to
> a target, e.g., a SPIN document, a ShEx document, or an ontology.  It
should
> be possible to transform the schema into an RDF graph in a standard way.
> Schemas may be accessible via one or more URLs, but it may require more
than
> URL dereferencing and parsing of the resultant document into a schema, for
> example importing may have to be performed.
>
> Constraint: A constraint is a component of a schema that says what needs
to
> be satisfied.  It may or may not include a scope (see below).
>
> Skoped Constraint: A constraint that indicates where it is to be satisfied
> on an RDF graph, e.g., a SPIN constraint (with both subject and object)
> or an OWL axiom.
> Example: Every person has at least one known name that is a string.
>
> Unskoped Constraint/Shape: A constraint that cannot be validated against
an
> RDF graph without some extra information on where it is to be satisfied,
> e.g., a labelled ShEx shape expression or SPIN ask or OWL description.
> Example: Named things are those things that have at least one name and all
>          their names are strings
> Example: Things with at least one name that is a string

I wonder if scoped and unscoped would be better reversed. For me, the
precedent set by the terms context-free (e.g. DTD) and context-sensitive
(e.g. W3C XML Schema or RNG) is worth leveraging.

-- 
ericP

> Constraint Condition/ShEx Rule: A component of a constraint
> that carries a condition that needs to be evaluated as part of validation,
> e.g., a ShEx rule, or an OWL description, or clause in a SPIN SPARQL
query.
> Example: At least one name and all names are strings
> Example: At least one name that is a string
>
> Recognition Constraint: A constraint that introduces vocabulary, e.g., a
> labeled ShEx expression or an OWL axiom defining a new class.
> Example: Named things are those things that have at least one name and all
>          their names are strings
> Example: Named people are those people that have at least one known name
>          that is a string.
>
> Recursive Recognition Constraints: A recognition constraint that refers to
> itself, either directly or indirectly.
> Example: Nicely named things are those things that have at least one name
>          and all their parts are nicely named things
> Example: Unnicely named things are those things that have at least one
name
>          and some of their parts are not unnicely named things
>
> Decoration: Additional information associated with a constraint, e.g, SPIN
> CONSTRUCT constructs or annotations on OWL axioms.  This information may
for
> example provide severity or other information about constraint violations.
> Example: This is the person name constraint
> Example: Violations produce warning for person name constraint violation
> Example: Return violating object and any of its names that are not strings
>
> Validation: The process of taking a schema and an RDF graph and maybe some
> other information, such as an ontology or some skoping information, and at
> least determining whether the RDF graph satisfies (does not violate) the
> schema.  Validation may produce more than just a boolean result if the
> constraints of the schema have decorations.