+
+```turtle
+<> tree:relation [
+ a tree:GreaterThanRelation ; # the type of the relation deciding the operator
+ tree:node ex:Node2 ; # for the left-hand: all members from here
+ tree:path dct:created ; # for the left-hand: the path pointing at the term(s) in the member
+ tree:value "2024-12-16T12:00:00Z"^^xsd:dateTime # the right-hand
+ ],[
+ a tree:SubstringRelation ;
+ tree:node ex:Node2 ;
+ tree:path dct:title ;
+ tree:value "osa"
+ ] .
+```
+
+
+
+In the example above the subtree reachable from `ex:Node2` will contain all remaining members that are both created later in time than the given timestamp *and* will have the provided substring in the title.
+The client can choose to prune all links to other nodes if this is the only thing it is interested in.
+Alternatively, the client can choose prune the subtree reachable from `ex:Node2` if it is specifically not looking for members with the given substring, *or* when it is not interested in members created later in time than the given timestamp.
+Alternatively, it can also score the relation based on the likelihood of returning useful results and created a priority queue that is processed until a top K of results have been found.
+Mind that when the client is specifically not interested in members created later than the given creation time, but does not understand the SubstringRelation, the client can still prune the relation.
+
+
+While each type of relation can decide on their own properties,
+relations will often use the `tree:path` to indicate the path from the member to the object on which the `tree:Relation` applies.
+For the different ways to express or handle a `tree:path`, we refer to [2.3.1 in the shacl specification](https://www.w3.org/TR/shacl/#x2.3.1-shacl-property-paths).
+All possible combinations of e.g., `sh:alternativePath` or `sh:inversePath` in the SHACL spec can be used.
+The resulting values of the evaluation of the `tree:path`, are the values that must be compared to the `tree:value` object.
+When multiple results from the path are found, they need to be interpreted as a logical OR: at least one of these values will fulfill the comparator.
+
+A client, in case it wants to process relations that use the `tree:path` property, MUST implement a matching algorithm to check whether the relation is relevant.
+I.e., a `tree:path` on `(rdfs:label [sh:alternativePath rdfs:comment ] )` will be useful when the client is tasked to filter on `rdfs:comment`.
+
+Note: A server is allowed to refer the `tree:path` to a property that is not materialized in the current response. For the client, if it also needs those triples, we assume in this spec that the client has another way of retrieving those, or already retrieved them from another source.
+
+## Comparing strings ## {#strings}
+
+String values have three specific type of relations: the `tree:PrefixRelation`, the `tree:SubstringRelation` and the `tree:SuffixRelation`.
+The string comparison happens using the unicode canonical equivalence.
+
+Issue: We experimented with server-chosen locales such that `ça suffit` can also be found when following a `tree:PrefixRelation` with a `tree:value "c"` (which at this moment is not supported). That would require an understanding of locales, and [browser/JavaScript support for locales is too low to be useful at this point](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl#Locale_identification_and_negotiation).
+
+Also the comparator relations such as `tree:GreaterThanRelation` can be used.
+The strings MUST then be compared using case sensitive unicode ordering.
+
+When a language is set on the `tree:value`, the relation only refers to these language strings. If no language is indicated, it refers to all (including those without).
+
+Particular to the `tree:SubstringRelation`, is that multiple `tree:value` properties can be set. This means the members properties will contain all of the given substrings.
+
+Issue: We need a flag for setting case insensitiveness: what will we use? In previous implementations `sh:flags "i"` was used.
+
+## Comparing named nodes ## {#named-nodes}
+
+When using comparator relations such as `tree:GreaterThanRelation`, named nodes MUST be compared as defined in the [ORDER BY section of the SPARQL specification](https://www.w3.org/TR/sparql11-query/#modOrderBy).
+
+## Comparing geospatial features ## {#geospatial}
+
+The `tree:GeospatiallyContainsRelation` is the relation that can be used to express all further members will be contained within a geospatial region defined by the WKT String in the `tree:value`.
+The client MUST consider the relation when it overlaps with the region of interest.
+
+When using `tree:GeospatiallyContainsRelation`, the `tree:path` MUST refer to a literal containing a WKT string, such as `geosparql:asWKT`.
+
+## Comparing time literals ## {#time}
+
+When using relations such as `tree:LessThanRelation` or `tree:GreaterThanRelation`, the time literals MUST to be compared according to these 3 possible data types: `xsd:date`, `xsd:dateTime` or `xsd:dateTimeStamp`.
+It is highly recommended to server developers to provide a timezone in the `tree:value`, which can be done in these datatypes themself.
+
+When no timezone is specified, the comparison needs to take place on the worst-case bound. For example a date `2022-01-01` without timezone thus represents a period of time of 48 hours from (`[`) `2021-12-31T12:00:00Z` until `2022-01-02T12:00:00Z` (`[`).
+
+# Search forms # {#searching}
+
+Searching through a TREE will allow you to immediately jump to the right `tree:Node` in a subtree.
+TREE relies on the [Hydra search specification](http://www.hydra-cg.com/spec/latest/core/#hydra:search) for its search forms.
+It does however extend Hydra with specific search properties (`hydra:IriTemplate`) for different types of search forms, and searches starting from a specific `tree:Node`, to which the search form is linked with `tree:search`.
+The behaviour of the search form fully depends on the specific property, for which TREE introduces a couple of specific properties:
+
+## Geospatial XYZ tiles search form ## {#xyztiles}
+
+Three properties allow to specify a geospatial XYZ tiles template (also known as slippy maps).
+ 1. `tree:longitudeTile` describes the X value
+ 2. `tree:latitudeTile` describes the Y value
+ 3. `tree:zoom` describes the zoom level
+
+All properties expect positive integers.
+
+
+ ```turtle
+ a tree:Collection ;
+ dcterms:title "A prototype tree:Collection for Linked OpenStreetMap’s roads"@en .
+
+
+This search form describes a specific search form that uses a quad tree. The zoom level describes the depth, the longitudeTile and latitudeTile describe the x and y index of the pagination. (e.g., on zoom level 0, there’s 1 tile, on zoom level 1, there are 4 tiles, etc.).
+
+## Searching through a list of objects ordered by time ## {#timesearch}
+
+Same as the previous example but with the predicate `tree:timeQuery` expecting an `xsd:dateTime`.
+This time however, when the page itself does not exist, a redirect is doing to happen to the page containing the timestamp.
+A `tree:path` can indicate the time predicate which is intended.
+
+
+ ```turtle
+ a tree:Collection ;
+ dcterms:title "An example collection with a time search view"@en ;
+ tree:view .
+
+ a tree:Node ;
+ tree:search [
+ a hydra:IriTemplate ;
+ hydra:template "https://example.org/{generatedAt}" ;
+ hydra:variableRepresentation hydra:BasicRepresentation ;
+ hydra:mapping [
+ a hydra:IriTemplateMapping ;
+ hydra:variable "generatedAt";
+ tree:path prov:generatedAtTime;
+ hydra:property tree:timeQuery;
+ hydra:required true
+ ]
+ ] .
+ ```
+
+
+path: vocabulary.mddiff --git a/shape-topologies.bs b/02-shape-topologies.bs similarity index 100% rename from shape-topologies.bs rename to 02-shape-topologies.bs diff --git a/03-discovery-specification.bs b/03-discovery-specification.bs new file mode 100644 index 0000000..751eddb --- /dev/null +++ b/03-discovery-specification.bs @@ -0,0 +1,124 @@ +
+Title: TREE Discovery and Context Information +Shortname: TREEDiscovery +Level: 1 +Status: w3c/CG-DRAFT +Markup Shorthands: markdown yes +Group: TREE hypermedia community group +URL: https://w3id.org/tree/specification/discovery +Repository: https://github.com/treecg/specification +Mailing List: public-treecg@w3.org +Mailing List Archives: https://lists.w3.org/Archives/Public/public-treecg/ +Editor: Pieter Colpaert, https://pietercolpaert.be +Abstract: + This specification defines how a client selects a specific dataset and search tree, as well as extracts relevant context information. ++ +# Definitions # {#overview} + +A `tree:Collection` is a subclass of `dcat:Dataset` ([[!vocab-dcat-3]]). +The specialization being that this particular dataset is a collection of _members_. + +A `tree:SearchTree` is a subClassOf `dcat:Distribution`. +The specialization being that it uses the main TREE specification to publish a search tree. + +A node from which all other nodes can be found is a `tree:RootNode`. + +Note: The `tree:SearchTree` and the `tree:RootNode` MAY be identified by the same IRI when no disambiguation is needed. + +A TREE client MUST be provided with a URL to start from, which we call the _entrypoint_. + +# Initializing a client with a url # {#starting-from} + +The goal of the client is to understand what `tree:Collection` it is using, and to find a `tree:RootNode` to start the traversal phase from. +This discovery specification extends the initialization step in the TREE specification, for the cases in which multiple options are possible. + +The client MUST dereference the URL, which will result in a set of quads. The client now MUST first perform the init step from the main specification. +If that did not return any result, then the client MUST check whether the URL before redirects (`E`) has been used in one of the following discovery patterns described in the subsections: + 1. `E` is a `tree:Collection`: then the client needs to [select the right search tree](#tree-search-trees) + 2. `E` is a `dcat:Dataset`: then the client needs to [select the right distribution or dataservice from a catalog](#dcat-dataset) + 3. `E` is a `ldes:EventStream`: then the client MAY take into account [LDES specific properties](#ldes) + 4. `E` is a `dcat:Distribution`: then the client needs to [process it accordingly](#dcat-distribution) + 5. `E` is a `dcat:DataService`: then the client needs to [process it accordingly](#dcat-dataservice) + 6. `E` is a catalog or is not explicitly mentioned: then it needs to select a dataset based on [shape information](#tree-collection-shapes) and [DCAT Catalog information](#dcat-catalog) + +## Selecting a collection via shapes ## {#tree-collection-shapes} + +When multiple collections are found by a client, it can choose to prune the collections based on the `tree:shape` property. +The `tree:shape` property will refer to a first `sh:NodeShape`. +The collection MAY be pruned in case there is no overlap with the properties the client needs. + +Issue: Will we document the precise algorithm to use? Should we extend shapes with cardinality approximations as well? + +## Selecting a collection via a catalog ## {#dcat-catalog} + +A DCAT Catalog is an overview of datasets, data services and distributions. +As TREE clients first need to select a dataset, and then a search tree to use, it aligns with how DCAT-AP works. +DCAT discovery extends upon the previous section in which a collection or dataset can be selected based on the `tree:shape` property. + +For now, we will assume the DCAT information is available in subject pages. + +Issue: Do we need more text on how to handle different types of DCAT interfaces? + +The dataset descriptions can be used for filtering the datasets available in a catalog to a list of datasets that can be useful for the client. +Such properties may include the spatial extent, the time extent, or how it is possibly a part of another `dcat:Dataset`. + +Issue: How precise do we need to be in this specification? + +When the `dcat:Dataset` is a `tree:Collection`, the DCAT catalog is going to contain a `dct:type` property with `https://w3id.org/tree#Collection` or `https://w3id.org/ldes#EventStream` as the object. + +## Choosing from multiple SearchTrees with TREE ## {#tree-search-trees} + +Issue: This is yet to be done + +## Selecting a search tree via a DCAT dataset ## {#dcat-dataset} + +The are two ways in which you can find a search tree from a dataset: via the distributions and via the data services. Both need to be tested. +Selecting a distribution or data service when multiple are available needs to be done based on [the search tree description](tree-search-trees). +If nothing is available, all need to be tested by processing them as exemplifie din the next subsections. + +### Selecting a search tree via DCAT Distribution ### {#dcat-distribution} + +`E dcat:distribution ?D . ?D dcat:downloadURL ?N .` then ?N is a rootnode of E. + +Issue: This is yet to be done + +### Selecting a search tree from a DCAT data service ### {#dcat-dataservice} + + * `?DS dcat:servesDataset E ; dcat:endpointURL ?U` or `E dcat:endpointURL ?U`, then the algorithm MUST repeat the algorithm with `?U` as the entrypoint. + +Issue: This is yet to be done + +## Linked Data Event Streams ## {#ldes} + +In case the client is not made for query answering, but only for setting up a replication and synchronization system, then there is a special type that can be used to indicate the search tree is made for this purpose: the `ldes:EventSource`. +Clients that want to prioritize taking a _full_ copy MAY give full priority to this server hint. + +
+```turtle
+E a ldes:EventSource ;
+ tree:rootNode|dcat:downloadURL .
+```
+
+
+# Extracting content information # {#context}
+
+Issue: This is yet to be done
+
+Context information enables a client to understand who the creator of a certain dataset is, when it was last changed, what other datasets it was derived from, etc.
+
+## DCAT and dcterms ## {#context-dcat}
+
+Issue: This is yet to be done
+
+## Provenance ## {#context-prov}
+
+Issue: This is yet to be done
+
+## Linked Data Event Streams ## {#context-ldes}
+
+Issue: This is yet to be done
+
+LDES (https://w3id.org/ldes/specification) is a way to evolve search trees in a consistent way. It defines every member as immutable, and a collection as append-only.
+Therefore, one can make sure to only process each member once.
+Extra terms are added, such as the concept of an EventStream, retention policies and a timestampPath.
diff --git a/TREE-overview.svg b/TREE-overview.svg
new file mode 100644
index 0000000..91d6adf
--- /dev/null
+++ b/TREE-overview.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/specs/4-provenance-and-summaries.md b/drafts/4-provenance-and-summaries.md
similarity index 100%
rename from specs/4-provenance-and-summaries.md
rename to drafts/4-provenance-and-summaries.md
diff --git a/specs/6-compatibility.md b/drafts/5-compatibilities.md
similarity index 92%
rename from specs/6-compatibility.md
rename to drafts/5-compatibilities.md
index 3904bff..658c43d 100644
--- a/specs/6-compatibility.md
+++ b/drafts/5-compatibilities.md
@@ -1,9 +1,5 @@
# Compatibility # {#compatibility}
-## DCAT ## {#dcat}
-
-[[!VOCAB-DCAT-2]] is the standard for Open Data Portals by W3C. In order to find TREE compliant datasets in data portals, there SHOULD be a dcat:endpointDescription from the dcat:DataService to the entrypoint where the tree:Collections and the tree:ViewDescriptions are listed. Furthermore, there SHOULD be a dct:conformsTo this URI: https://w3id.org/tree/specification.
-
## Hydra ## {#hydra}
A tree:Collection is compatible with the [Hydra Collections specification](https://www.hydra-cg.com/spec/latest/core/#collections). However, instead of hydra:view, we use tree:view and do not link to a hydra:PartialCollectionView but to a tree:Node.
diff --git a/specs/5-imports.md b/drafts/6-imports.md
similarity index 100%
rename from specs/5-imports.md
rename to drafts/6-imports.md
diff --git a/examples/eventstreams/README.md b/examples/eventstreams/README.md
deleted file mode 100644
index 4caf2f5..0000000
--- a/examples/eventstreams/README.md
+++ /dev/null
@@ -1,82 +0,0 @@
-# Example: Event Streams
-
-Event streams in TREE are defined as a `tree:Collection` of members with event-like objects. Each of such member has a timestamp (preferably with range `xsd:dateTime`) such as a `prov:generatedAtTime` indicating the time at which the event was created.
-On each collection, a `tree:shape` __should__ be set that links to a SHACL shape to which the events comply.
-
-Example:
-
-```turtle
--Title: The TREE hypermedia specification -Shortname: TREE -Level: 1 -Status: w3c/CG-DRAFT -Markup Shorthands: markdown yes -Group: TREE hypermedia community group -URL: https://w3id.org/tree/specification -Repository: https://github.com/treecg/specification -Mailing List: public-treecg@w3.org -Mailing List Archives: https://lists.w3.org/Archives/Public/public-treecg/ -Editor: Pieter Colpaert, https://pietercolpaert.be -Abstract: - The TREE hypermedia specification enables data publishers and API developers to describe datasets as collections of entities, called “the members”. - It then allows to create one or more views of this collection. - A view allows organizing the members into multiple pages or nodes, and these nodes are interlinked using relations and/or search forms. - This way, a user agent that can interpret the TREE hypermedia controls can find the most efficient way to the members of interest to them. -- -
path: specs/0-introduction.md-
path: specs/1-discovery.md-
path: specs/2-traversing.md-
path: specs/3-search.md-
path: specs/5-imports.md-
path: specs/6-compatibility.md- -
path: vocabulary.mddiff --git a/specs/0-introduction.md b/specs/0-introduction.md deleted file mode 100644 index 07b2335..0000000 --- a/specs/0-introduction.md +++ /dev/null @@ -1,112 +0,0 @@ -# Overview # {#overview} - -
tree:Collection is a subclass of dcat:Dataset ([[!vocab-dcat-3]]). The specialization being that it is a DCAT dataset a collection of members. It typically has these properties when described in a node:
- - tree:member points at the first focus node from which to retrieve and extract all quads of a member.
- - tree:view points to the current tree:Node you’re visiting.
- - tree:shape indicates the [[!SHACL]] shape to which each member in the collection adheres.
- - tree:viewDescription links to a description of the view (a tree:ViewDescription). Multiple descriptions MAY be provided that MUST be combined.
- * a tree:Node: is a page on which relations to other pages are described through the tree:relation predicate, and/or through which a next tree:Node can be found by using the tree:search form.
- * a tree:Relation is a relation from one node to another. An extension of this class indicates a specific type of relation (e.g., a tree:GreaterThanRelation). A relation typically has these properties:
- - a tree:node the URL of the other node
- - a tree:path indicating to which of the members' properties this relation applies
- - a tree:value indicating a value constraint on the members' values
- - a tree:remainingItems defining how many members can be reached when following this relation
- * a tree:ViewDescription is a subclass of dcat:DataService and serves a tree:Collection.
- - a tree:search describes a search form that allows an agent to jump to a specific tree:Node.
-
-The first step when creating a TREE hypermedia interface is defining a collection of members:
-
-
- ```turtle
- ex:Collection1 a tree:Collection;
- rdfs:label "A Collection of subjects"@en;
- tree:member ex:Subject1, ex:Subject2 .
-
- ex:Subject1 a ex:Subject ;
- rdfs:label "Subject 1" ;
- ex:value 1 .
-
- ex:Subject2 a ex:Subject ;
- rdfs:label "Subject 2" ;
- ex:value 2 .
- ```
-
-
-From the moment this collection of members grows too large for one page, a fragmentation needs to be created in which an initial set of member can be found on an entry node, and more members can be found by interpreting the TREE hypermedia controls. This is illustrated by the next example:
-
-
- ```turtle
- > HTTP GET https://example.org/Node1
-
- ex:Collection1 a tree:Collection;
- tree:view ex:Node1 ;
- tree:member ex:Subject1, ex:Subject2 .
-
- ex:Node1 a tree:Node ;
- tree:relation ex:R1,ex:R2 .
-
- ex:R1 a tree:GreaterThanOrEqualToRelation ;
- tree:node ex:Node3 ; # This is the URL of another page
- tree:value 3;
- tree:path ex:value .
-
- ex:R1 a tree:LessThanRelation ; # This is very useful for a client that is looking for a value 10 or greater
- tree:node ex:Node3 ; # This is the URL of another page
- tree:value 10;
- tree:remainingItems 7 ;
- tree:path ex:value .
-
- ex:R2 a tree:GreaterThanOrEqualToRelation ;
- tree:node ex:Node4 ; # This is the URL of another page
- tree:value 10;
- tree:remainingItems 10 ;
- tree:path ex:value .
-
- ex:Subject1 a ex:Subject ;
- rdfs:label "Subject 1" ;
- ex:value 1 .
-
- ex:Subject2 a ex:Subject ;
- rdfs:label "Subject 2" ;
- ex:value 2 .
- ```
-
-
-
- Thanks to the [member extraction algorithm](#member-extraction-algorithm), a data publisher can choose to define their members in different ways:
- 1. As in the examples above: all quads with the object of the
-
-# Definitions # {#formalizations}
-
-A tree:member quads as a subject (and recursively the quads of their blank nodes) are by default included (see also [[!CBD]]), except when they would explicitely not be included in case 3, when the shape would be closed.
- 2. Out of band / in band:
- - when no quads of a member have been found, the member will be dereferenced. This allows to publish the member on a separate page.
- - part of the member can be maintained elsewhere when a shape is defined (see 3)
- 3. By defining a more complex shape with tree:shape, also nested entities can be included in the member
- 4. By putting the triples in a named graph of the object of tree:member, all these triples will be matched.
-tree:Collection is a set of tree:Members. The set of members MAY be empty.
-
-A tree:Member is a set of (at least one) quad(s) defined by the member extraction algorithm (next subsection).
-
-A tree:Node is a dereferenceable resource containing tree:Relations and a subset of (⊆) members of the collection. In a tree:Node, both the set of tree:Relations as the subset of members MAY be empty. The same member MAY be contained in multiple nodes.
-
-A tree:Relation is a function denoting a conditional link to another tree:Node.
-
-A tree:Node, apart from the root node, has exactly one other tree:Node linking into it through one or more relations.
-
-Note: The condition of multiple tree:Relations to the same tree:Node MUST be combined with a logical AND.
-
-A View is a specific set of interlinked tree:Nodes, that together contain all members in a collection. A specific view will adhere to a certain growth or tree balancing strategy. In one View, completeness MUST be guaranteed, unless the View has a retention policy which becomes possible in LDES.
-
-A tree:search form is an IRI template, that when filled out with the right parameters becomes a tree:Node IRI, or when dereferenced will redirect to a tree:Node from which all members in the collection that adhere to the described comparator can be found.
-
-## The member extraction algorithm ## {#member-extraction-algorithm}
-
-The set of quads the are part of the member, are defined by the [shape templates algorithm](https://w3id.org/tree/specification/shape-templates), provided as a separate report to this specification.
-It is a combination of Concise Bounded Descriptions, named graphs and Shape Templates.
-The latter uses the sh:NodeShape from the tree:shape property on the collections as an indication of the topology of the member graph.
-
-Note: The way we process SHACL shapes into Shape Template is important to understand in order to know when an HTTP request will be triggered when designing SHACL shapes. A cardinality constraint not being exactly matched or a sh:pattern not being respected will not trigger an HTTP request, and instead just add the invalid quads to the Member. This is a design choice: we only define triggers for HTTP request from the SHACL shape to come to a complete set of quads describing the member the data publisher pointed at using tree:member.
diff --git a/specs/1-discovery.md b/specs/1-discovery.md
deleted file mode 100644
index f6bbc05..0000000
--- a/specs/1-discovery.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# Discovery and source selection# {#hypermedia}
-
-TREE tackles discovery and source selection on three levels: i) interface discovery, ii) view discovery, and iii) dataset discovery.
-Interface discovery discovers what collection the current page is part of, and discovers what the next possible HTTP requests are through relations and search forms.
-One dataset can have multiple views that can be published across different servers, selecting one for a certain use case is part of the view discovery.
-Dataset discovery is then selecting a tree:Collection of interest.
-
-
-## Interface discovery ## {#interface-discovery}
-
-Interface discovery starts when a URL is provided to a specific tree:Node.
-A node from which all members of a collection can be discovered (an “entry node”), can be found through a triple stating ex:C1 tree:view ex:N1 with ex:C1 being a tree:Collection and ex:N1 being a tree:Node.
-
-When the current page is a tree:Node, there MUST be a property linking the current page URL to the URI of the tree:Collection. However, not from all tree:Nodes all members can be reached, and therefore 2 other properties can be used: void:subset, or the inverse property, dcterms:isPartOf.
-
-ex:C1 tree:view <> . links the current page to the tree:Collection.
-
-We refer to next chapters for traversing across multiple relations, or for using search forms.
-
-## View discovery ## {#multiple-views}
-
-Todo: This will be reworked
-
-Note: How a client picks the right view is use case specific. The tree:ViewDescription’s properties can help in that regards.
-
-In order to prioritize a specific view link, the relations and search forms in the entry nodes can be studied for their relation types, path or remaining items.
-The class tree:ViewDescription indicates a specific TREE structure on a tree:Collection.
-Through the property tree:viewDescription a tree:Node can link to an entity that describes the view, and can be reused in data portals as the dcat:DataService.
-
-
- ```turtle
- ## What can be found in a tree:Node
- ex:N1 a tree:Node ;
- tree:viewDescription ex:View1 .
-
- ex:C1 a tree:Collection ;
- tree:view ex:N1 .
-
- ## What can be found on a data portal
- ex:C1 a dcat:Dataset .
- ex:View1 a tree:ViewDescription, dcat:DataService ;
- dcat:endpointURL ex:N1 ; # The entry point that can be advertised in a data portal
- dcat:servesDataset ex:C1 .
- ```
-
-
-When there is no tree:viewDescription property in this page, a client either already discovered the description of this view in an earlier tree:Node, either the current tree:Node is implicitly the ViewDescription. Therefore, when the property path tree:view → tree:viewDescription does not yield a result, the view properties MUST be extracted from the object of the tree:view triple.
-A tree:Node can also be double typed as the tree:ViewDescription. A client must thus check for ViewDescriptions on both the current node without the tree:viewDescription qualification, as on the current node with the tree:viewDescription link.
-
-
-## Dataset discovery ## {#multiple-collections}
-
-When multiple collections are found by a client, it can choose to prune the collections based on the tree:shape property.
-Therefore a data publisher SHOULD annotate a tree:Collection instance with a SHACL shape.
-The tree:shape points to a SHACL description of the shape (sh:NodeShape).
-
-Note: the shape can be a blank node, or a named node on which you should follow your nose when it is defined at a different HTTP URL.
-
-Note: For compatibility with the [Solid specifications](https://solidproject.org/TR/), a ShEx shape may also be given (see the chapter on compatibility bellow).
diff --git a/specs/2-traversing.md b/specs/2-traversing.md
deleted file mode 100644
index 1238e84..0000000
--- a/specs/2-traversing.md
+++ /dev/null
@@ -1,76 +0,0 @@
-# The tree:Relations # {#relations}
-
-The initial configuration of the tree:Collection and the description of the view is always provided when the view has been discovered, either in a separate document describing the view, either in the entry node itself. The configuration MUST be reused on any subsequent tree:Node.
-
-While discovering and traversing the interface, a client MUST take the descriptions on top of the Node, the View and the Collection with it.
-
-## Traversing relations ## {#traversing}
-
-A tree:Node element MAY have one or more tree:relation properties. A relation is an entity of the type tree:Relation, and MAY have a more specific type. A tree:Relation MUST have one tree:node object of the type tree:Node. By default, all nodes need to be followed, unless the client is able to select this relation for pruning (see next section).
-
-The tree:Relation’s tree:value SHOULD be set. The object of tree:value SHOULD be accompanied by a data type when it is a literal value.
-
-Every tree:Relation SHOULD have a tree:path, indicating the path from the member to the object on which the tree:Relation applies. For the different ways to express or handle a tree:path, we refer to [2.3.1 in the shacl specification](https://www.w3.org/TR/shacl/#x2.3.1-shacl-property-paths). All possible combinations of e.g., shacl:alternativePath, shacl:inversePath or shacl:inLanguage in the SHACL spec can be used. When shacl:alternativePath is used, the order in the list will define the importance of the order when evaluating the tree:Relation. A wildcard in the path is limited to the tree:shape of the tree:Collection.
-The result of the evaluation of the tree:path, is the value that must be compared to the tree:value.
-
-Every tree:Relation MAY provide a tree:remainingItems. A client MAY use tree:remainingItems to estimate the completeness of the downloaded elements to the end-user.
-
-Note: When traversing, a client SHOULD keep a list of already visited pages, as despite this being the TREE spec, circular references and back-links are not explicitly prohibited.
-
-A tree:import MAY be defined in the tree:Relation instance. When there is a tree:path defined, and when the relation is flagged interesting to follow, the import link needs to be downloaded in order to find the necessary literals to be compared (it is thus already a tree:ConditionalImport.
-
-Note: An example of a tree:import is given [in the repository](https://github.com/TREEcg/specification/blob/master/examples/geospatially-ordered-public-transport/first.ttl#L27).
-
-When dereferencing the object of a tree:node triple, the client MUST follow redirects. The URL to be used as the tree:Node URL is the last URL after redirects.
-
-Note: This enables rebalancing search trees.
-
-## Fallbacks ## {#fallbacks}
-
-When there is no tree:view triple provided, a client MUST use the tree:Collection from the previous page and still continue extracting members, and extract further relations defined on the current page URL.
-
-When there are no tree:members and/or no tree:Collection defined, then still a tree:Relation can be defined. The tree:path in the tree:Relation then refers to a pattern that can start from every triple in the page.
-
-When no tree:path is defined, the tree:value MUST be compared to all members’ triples that *can be compared to* the tree:value as defined by the type of the relation (or when no members or collection are defined, on every triple in the page).
-When due to rdfs:range incompatibility, the object cannot be compared, the object will not be considered for comparison.
-
-Note: This may enable server developers to indicate an index on all literals of the members (e.g., a prefix relation on title, description and body text) without having to indicate all of the alternative paths in the tree:path.
-
-The target object of a tree:path SHOULD be materialized in the current Node document, but when it is not, the object MAY be considered implicit on the condition both tree:path and tree:member are defined.
-In contrast to sh:path, a tree:path MAY refer to an implicit property and may not be materialized in the current response. This may break SPARQL processors that did not yet come across the object before in their query plan. However, the tree may still be useful for query processors that, for example, prioritize queries according to the user’s location, and first download nodes that are nearby the user. Therefore, the materialized location of the object is not needed. While not recommended, possible heuristics could try to infer the data, could try to fetch it through another tree:Collection, or retrieve it using URI dereferencing.
-
-## Specific relations ## {#relationsubclasses}
-
-When the *only* type given for a certain Relation is tree:Relation, then the client must dereference all of the nodes. While this may seem useless, it can be used for the same use case as a hydra:PartialCollectionView.
-
-For other types check the chapter on relation types in the vocabulary [](#Relation).
-
-### Comparing strings ### {#strings}
-
-String values have three specific type of relations: the tree:PrefixRelation, the tree:SubstringRelation and the tree:SuffixRelation.
-
-Note: We experimented with server-chosen locales such that ça suffit can also be found when following a tree:PrefixRelation with a tree:value "c" (which at this moment is not supported). That would require an understanding of locales, and [browser/JavaScript support for locales is too low to be useful at this point](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl#Locale_identification_and_negotiation).
-
-Also the comparator relations such as tree:GreaterThanRelation can be used.
-The strings MUST then be compared according to *case sensitive unicode ordering*.
-
-When a tree:path is defined, mind that you also may have to check the language of the element using the property shacl:inLanguage
-More languages MAY be set.
-When no language is set, all strings are compared.
-
-Note: If you want to have one resource containing both e and é as a prefix, you will have to create multiple relations to the same tree:Node.
-
-### Comparing named nodes ### {#named-nodes}
-
-When using comparator relations such as tree:GreaterThanRelation, named nodes must be compared as defined in the [ORDER BY section of the SPARQL specification](https://www.w3.org/TR/sparql11-query/#modOrderBy).
-
-### Comparing geospatial features ### {#geospatial}
-
-The tree:GeospatiallyContainsRelation is the relation than can be used to express all further members will be contained within a geospatial region defined by the WKT String in the tree:value.
-
-When using tree:GeospatiallyContainsRelation, the tree:path MUST refer to a literal containing a WKT string, such as geosparql:asWKT.
-
-### Comparing time literals ### {#time}
-
-When using relations such as tree:LessThanRelation or tree:GreaterThanRelation, the time literals need to be compared according to these 3 possible data types: xsd:date, xsd:dateTime or xsd:dateTimeStamp.
-
diff --git a/specs/3-search.md b/specs/3-search.md
deleted file mode 100644
index 2d7ea5a..0000000
--- a/specs/3-search.md
+++ /dev/null
@@ -1,83 +0,0 @@
-# Search forms # {#searching}
-
-Searching through a TREE will allow you to immediately jump to the right tree:Node.
-TREE relies on the [Hydra search specification](http://www.hydra-cg.com/spec/latest/core/#hydra:search) for its search forms.
-It does however extend Hydra with specific search properties (hydra:IriTemplate) for different types of search forms, and searches starting from a tree:ViewDescription, to which the search form is linked with tree:search.
-The behaviour of the search form fully depends on the specific property, for which TREE introduces a couple of specific properties:
-
-## Geospatial XYZ tiles search form ## {#xyztiles}
-
-Three properties allow to specify a geospatial XYZ tiles template (also known as slippy maps).
- 1. tree:longitudeTile describes the X value
- 2. tree:latitudeTile descrbes the Y value
- 3. tree:zoom describes the zoom level
-
-All properties expect positive integers.
-
-
- ```turtle
- a tree:Collection ;
- dcterms:title "A prototype tree:Collection for Linked OpenStreetMap’s roads"@en ;
- tree:view .
-
- a tree:Node ;
- tree:viewDescription
-
-This search form describes a specific search form that uses a quad tree. The zoom level describes the depth, the longitudeTile and latitudeTile describe the x and y index of the fragmentation. (e.g., on zoom level 0, there’s 1 tile, on zoom level 1, there are 4 tiles, etc.).
-
-## Searching through a list of objects ordered by time ## {#timesearch}
-
-Same as the previous example but with the predicate tree:timeQuery expecting an xsd:dateTime.
-This time however, when the page itself does not exist, a redirect is doing to happen to the page containing the timestamp.
-A tree:path can indicate the time predicate which is intended.
-
-
- ```turtle
- a tree:Collection ;
- dcterms:title "An example collection with a time search view"@en ;
- tree:view .
-
- a tree:Node ;
- tree:viewDescription .
-
- a tree:ViewDescription ;
- tree:search [
- a hydra:IriTemplate ;
- hydra:template "https://example.org/{generatedAt}" ;
- hydra:variableRepresentation hydra:BasicRepresentation ;
- hydra:mapping [
- a hydra:IriTemplateMapping ;
- hydra:variable "generatedAt";
- tree:path prov:generatedAtTime;
- hydra:property tree:timeQuery;
- hydra:required true
- ]
- ] .
- ```
-
diff --git a/tree.ttl b/tree.ttl
index 7c82975..de2594d 100644
--- a/tree.ttl
+++ b/tree.ttl
@@ -23,15 +23,13 @@
tree: a foaf:Document ;
foaf:primaryTopic tree:Ontology;
cc:license tree:Relation has specific sub-classes that implement a more sp
A class to import a file or a stream based on a tree:path of properties. This way it can import the necessary data for complying to the SHACL shape, or evaluating a relation type.
-### tree:ViewDescription ### {#ViewDescription}
-
-Describes a specific TREE structure on top of the tree:Collection.
-
## Properties ## {#properties}
### tree:relation ### {#relation}
@@ -151,8 +147,6 @@ A search form parameter: accompagnied by a tree:path, it indicates
### tree:viewDescription ### {#viewDescription}
-Links together a tree:Node with its description of this TREE structure.
+Links together any HTTP response with a view description on which things like retention policies, contact information of a server, etc. can be found.
**Domain**: tree:Node
-
-**Range**: tree:ViewDescription