Datanode

A data node may be metadata about another.

This property basically represents the proximity of some data to other. Two parts of the same dataset are adjacents each other.

This, along with its inverse haveAttached , are considered to model the "physical" dependency between data. You need to have access to the first in order to access the second, for example. An obvious example is an email and its attachments.

Data are cleaned to better fit a purpose, sometimes making explicit potential capabilities. We intend cleaning in a broad sense, including activities like fixes in the syntax of the data or pruning of unfitting data with relation to a given task.

This relation specifies the fact that the object includes the subject. However, this does not mean that the subject is included as-is. Therefore, a combination implies derivation but not partition.

We intend consistency in a general sense: two data nodes are consistent because they agree (ie, they do not disagree...).

It can be the case that a single data node is verified to be consistent (with relation to some logic). It can then be marked to be consistent with itself.

This relates a datanode to any datanode being an object in its representation.

This relates a datanode to any datanode being an object in its representation.

Two nodes have different potential. Two data nodes using different vocabularies or two copies of the same data in different places.

Two datanodes do not share any population.

Two datanodes do not share any set of vocabulary terms.

Relates a datanode to another that is the result of a process that removes any personal identifiable information. The resulting datanode is meant to play the role of its origin in the application.

We relate with this property a data node to a collection of attributes used in it. We distinguish attributes from relations because the first does not qualify the range entity but only the domain entity (saying that a person is 1.82m tall does not change our knowledge about 1.82m).

Relates a datanode to another that is the result of some computation on its data.

Indicates a data node which includes information that is now old or outdated. We don't indicate it to be also a part, this is to discuss.

We choose the term descriptor to indicate generically the element used to bind/map/qualify a value with respect to its entity. Practically, this term maps to

• "Field" in Object Oriented Programming;
• "Predicate" in First Order Logic
• Column identifier (Attribute) in Relation Database terminology
• rdf:Property in the Resource Description Framework

Relates a datanode to another that formalize the information obtained as a result of an information extraction process, for example a data mining process.

Relates a datanode to the collection of the identifiers of its population.

Relates a datanode to another including a set of logical inferences deduced from the first.

This property refer to the semantic of reification in RDF.

Relates a datanode to an excerpt of its population, with some, non specified, attributes.

Are we sure a stand-in is always a derivation?

Statistics are at the same time computations and metadata of a source datanode.

Update is considered in a general meaning of having a role meant to better reflect the referred world.

The range of this property is a data node which enumerates a set of terms that are all used by the subject data node as identifiers (eventually to name structural elements, like attribute names or types).

When a data node :hasVocabulary another, we expect the latter to be the collection of terms used by the data node to name its properties and types.
How to know if there is some term that is not part of that vocabulary? In other words, is it relevant to know whether a vocabulary is complete or not wrt some data?

It can be the case that a single data node is corrupted to some respect. It can then be marked to be inconsistent with itself.

We intend consistency in a general sense: two data nodes are inconsistent because they do not agree.

This relation indicates that a data node is the origin of another, in the sense that the second have been produced using the first as information source.

This datanode enumerate a set of terms that are all used by the related datanode.

This is used to relate a data node to its metadata.

Relates a datanode to another that is the direct next version.

Two data nodes have similar potential, their domains overlap.

Two datanodes share some population.

Two datanodes share a set of vocabulary terms.

Refactoring is transforming to make it simpler, optimized and more efficient for a target task.

It looks like there could be a more generic property here, which refer to the fact of sharing some signatures (identifiers), without assuming an order or direction of the reference. Two data nodes may simply use the same identifier independently from the intention of making a reference to anything else (then the identifier itself). Does this make sense?

The subject of this property includes a mention to something which is (included in) another data node.
Talking about RDF datasets, this refer to the mention of a URI belonging to another dataset. For example, a dataset about employees could mention a Geonames location.

This is the Top Property of Datanode.

Remodelling refer to the translation of the data to another symbolic structure (model), while keeping the same interpretation.

Having the same capability implies having the same population and the same vocabulary. In colloquial terms, the same data is described in the same terms.

The second is intended to be a self contained model that is (even partly) used in the data node.

We distinguish the schema and the vocabulary as follows. A vocabulary is the enumeration of a set of terms. A schema organize a set of terms in a system of some sort. A list of body parts is not the anatomy of a body. The furniture is not an interior design model.

Use this property to represent a temporal relation between two data nodes that are meant to be the same at a different point in time. The property is symmetric and does not specify a direction.
This property is not transitive. While it can be argued that the identity of something tracked temporarly should not change, thus implying transitivity, we want support the case when a data note has more then one following version (branching). Avoiding transitivity allows it.