Skip to content

Commit 4d6ecf8

Browse files
pietercolpaertpietercolpaert
committed
Compatibilities to draft
1 parent 75a8881 commit 4d6ecf8

File tree

2 files changed

+113
-114
lines changed

2 files changed

+113
-114
lines changed

‎01-tree-specification.bs

-114
Original file line numberDiff line numberDiff line change
@@ -284,118 +284,4 @@ A <code>tree:path</code> can indicate the time predicate which is intended.
284284
```
285285
</div>
286286

287-
# Compatibility # {#compatibility}
288-
289-
## Hydra ## {#hydra}
290-
291-
A <code>tree:Collection</code> is compatible with the [Hydra Collections specification](https://www.hydra-cg.com/spec/latest/core/#collections). However, instead of <code>hydra:view</code>, we use <code>tree:view</code> and do not link to a <code>hydra:PartialCollectionView</code> but to a <code>tree:Node</code>.
292-
A <code>hydra:Collection</code> can thus also be extended with a <code>tree:shape</code> and <code>tree:view</code>.
293-
When this is done, also <code>hydra:member</code> can be used instead of <code>tree:member</code>.
294-
295-
<code>hydra:totalItems</code> can be used to indicate the total amount of elements in the collection.
296-
Hydra paging controls such as <code>hydra:next</code> and <code>hydra:previous</code> are semantically equivalent to a <code>tree:Relation</code> element that only contains a <code>tree:node</code> property.
297-
298-
## Activity Streams 2.0 ## {#activitystreams}
299-
300-
A <code>tree:Collection</code> is also compatible with [[!activitystreams-core]]’s specification of [paged collections](https://www.w3.org/TR/activitystreams-core/#collections).
301-
Instead of <code>dcterms:isPartOf</code>, also <code>as:partOf</code> can be used to indicate that the current page is part of the full collection.
302-
While Hydra and TREE link to the members of the collection by using the specific collection as a subject, Activity Streams 2.0 (AS) indicates a member starting from the page URL.
303-
Therefore, when using AS collections, a client implementation should gather the members from the <code>tree:Node</code> or <code>as:CollectionPage</code> instead.
304-
305-
<code>as:totalItems</code> can be used to indicate the total amount of elements in the collection.
306-
307-
AS paging controls such as <code>as:next</code>and <code>as:previous</code> are semantically equivalent to a <code>tree:Relation</code> element that only contains a <code>tree:node</code> property.
308-
309-
## LDP Containers ## {#ldp}
310-
311-
In [[!LDP]], the <code>tree:view</code> can be applied on top of the <code>ldp:Container</code> instance.
312-
Members can be found through <code>ldp:contains</code>, and/or through the indirect <code>ldp:membershipResource</code> and <code>ldp:hasMemberRelation</code> or <code>ldp:isMemberOfRelation</code> construct.
313-
314-
If this container is paged by the [[!ldp-paging]] (chapter 7) spec, then this MUST be ignored.
315-
316-
If there is an ordering, this MUST be ignored by TREE clients (the relations contain all necessary information for pruning).
317-
318-
## Shape trees ## {#shapetrees}
319-
320-
[The Shape Trees specification](https://shapetrees.org/TR/specification/) is specifically built to work within existing ecosystems.
321-
As it was conceived to interoperate with LDP, the term Container in the Shape Trees spec can also be interpreted as a <code>tree:Collection</code>.
322-
Shape Trees can help in the source selection of what specific <code>tree:Collection</code> to pick for your goal, and may add hierarchies to a set of <code>tree:Collection</code>s.
323-
A client MAY infer a <code>tree:shape</code> of the collection through the <code>st:validatedBy</code> property of the Shapes Tree.
324-
325-
An example of a collection using Shape Tree terms. In this example a sensor with some observations is validated by using a [Shape Expressions](http://shex.io/shex-semantics/) (ShEx) file.
326-
327-
<div class="example">
328-
```turtle
329-
@prefix sosa: <http://www.w3.org/ns/sosa/> .
330-
@prefix om: <http://www.ontology-of-units-of-measure.org/resource/om-2/> .
331-
@prefix ldp: <http://www.w3.org/ns/ldp#> .
332-
333-
<2021.ttl#Collection> a ldp:Container;
334-
st:validatedBy <Sensor.shex#Sensor>;
335-
tree:member <sensor1>, <sensor2> .
336-
337-
<sensor1>
338-
a sosa:Sensor;
339-
sosa:madeObservation
340-
<sensor1-observation1>,
341-
<sensor1-observation2>;
342-
sosa:observes om:Temperature .
343-
344-
<sensor1-observation1>
345-
a sosa:Observation;
346-
sosa:observedProperty om:Temperature;
347-
sosa:madeBySensor <sensor1>;
348-
sosa:hasResult <result1>;
349-
sosa:resultTime "2020-08-25T07:05:31Z"^^xsd:dateTime .
350-
351-
<result1> a om:Measure;
352-
om:hasValue "22"^^xsd:float;
353-
om:hasUnit om:degreeCelsius .
354-
355-
<sensor1-observation2>
356-
a sosa:Observation;
357-
sosa:observedProperty om:Temperature;
358-
sosa:madeBySensor <sensor1>;
359-
sosa:hasResult <result2>;
360-
sosa:resultTime "2020-08-25T07:05:32Z"^^xsd:dateTime .
361-
362-
<result2> a om:Measure;
363-
om:hasValue "22"^^xsd:float;
364-
om:hasUnit om:degreeCelsius .
365-
366-
<sensor2>
367-
a sosa:Sensor;
368-
sosa:observes om:Temperature .
369-
```
370-
371-
And its corresponding ShEx file (called Sensor.shex)
372-
373-
```shex
374-
PREFIX sosa: <http://www.w3.org/ns/sosa/>
375-
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
376-
PREFIX om: <http://www.ontology-of-units-of-measure.org/resource/om-2/>
377-
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
378-
379-
<#Sensor> {
380-
a [sosa:Sensor] ;
381-
sosa:observes [om:Temperature] ;
382-
sosa:madeObservation @<#TemperatureObservation> *
383-
}
384-
385-
<#TemperatureObservation> {
386-
a [sosa:Observation] ;
387-
sosa:resultTime xsd:dateTime ;
388-
sosa:madeBySensor @<#Sensor> ? ;
389-
sosa:observedProperty [om:Temperature];
390-
sosa:hasResult @<#TemperatureResult>
391-
}
392-
393-
<#TemperatureResult> {
394-
a [om:Measure];
395-
om:hasValue xsd:float ;
396-
om:hasUnit [om:degreeCelsius]
397-
}
398-
```
399-
</div>
400-
401287
<pre class=include>path: vocabulary.md</pre>

‎drafts/5-compatibilities.md

+113
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,113 @@
1+
# Compatibility # {#compatibility}
2+
3+
## Hydra ## {#hydra}
4+
5+
A <code>tree:Collection</code> is compatible with the [Hydra Collections specification](https://www.hydra-cg.com/spec/latest/core/#collections). However, instead of <code>hydra:view</code>, we use <code>tree:view</code> and do not link to a <code>hydra:PartialCollectionView</code> but to a <code>tree:Node</code>.
6+
A <code>hydra:Collection</code> can thus also be extended with a <code>tree:shape</code> and <code>tree:view</code>.
7+
When this is done, also <code>hydra:member</code> can be used instead of <code>tree:member</code>.
8+
9+
<code>hydra:totalItems</code> can be used to indicate the total amount of elements in the collection.
10+
Hydra paging controls such as <code>hydra:next</code> and <code>hydra:previous</code> are semantically equivalent to a <code>tree:Relation</code> element that only contains a <code>tree:node</code> property.
11+
12+
## Activity Streams 2.0 ## {#activitystreams}
13+
14+
A <code>tree:Collection</code> is also compatible with [[!activitystreams-core]]’s specification of [paged collections](https://www.w3.org/TR/activitystreams-core/#collections).
15+
Instead of <code>dcterms:isPartOf</code>, also <code>as:partOf</code> can be used to indicate that the current page is part of the full collection.
16+
While Hydra and TREE link to the members of the collection by using the specific collection as a subject, Activity Streams 2.0 (AS) indicates a member starting from the page URL.
17+
Therefore, when using AS collections, a client implementation should gather the members from the <code>tree:Node</code> or <code>as:CollectionPage</code> instead.
18+
19+
<code>as:totalItems</code> can be used to indicate the total amount of elements in the collection.
20+
21+
AS paging controls such as <code>as:next</code>and <code>as:previous</code> are semantically equivalent to a <code>tree:Relation</code> element that only contains a <code>tree:node</code> property.
22+
23+
## LDP Containers ## {#ldp}
24+
25+
In [[!LDP]], the <code>tree:view</code> can be applied on top of the <code>ldp:Container</code> instance.
26+
Members can be found through <code>ldp:contains</code>, and/or through the indirect <code>ldp:membershipResource</code> and <code>ldp:hasMemberRelation</code> or <code>ldp:isMemberOfRelation</code> construct.
27+
28+
If this container is paged by the [[!ldp-paging]] (chapter 7) spec, then this MUST be ignored.
29+
30+
If there is an ordering, this MUST be ignored by TREE clients (the relations contain all necessary information for pruning).
31+
32+
## Shape trees ## {#shapetrees}
33+
34+
[The Shape Trees specification](https://shapetrees.org/TR/specification/) is specifically built to work within existing ecosystems.
35+
As it was conceived to interoperate with LDP, the term Container in the Shape Trees spec can also be interpreted as a <code>tree:Collection</code>.
36+
Shape Trees can help in the source selection of what specific <code>tree:Collection</code> to pick for your goal, and may add hierarchies to a set of <code>tree:Collection</code>s.
37+
A client MAY infer a <code>tree:shape</code> of the collection through the <code>st:validatedBy</code> property of the Shapes Tree.
38+
39+
An example of a collection using Shape Tree terms. In this example a sensor with some observations is validated by using a [Shape Expressions](http://shex.io/shex-semantics/) (ShEx) file.
40+
41+
<div class="example">
42+
```turtle
43+
@prefix sosa: <http://www.w3.org/ns/sosa/> .
44+
@prefix om: <http://www.ontology-of-units-of-measure.org/resource/om-2/> .
45+
@prefix ldp: <http://www.w3.org/ns/ldp#> .
46+
47+
<2021.ttl#Collection> a ldp:Container;
48+
st:validatedBy <Sensor.shex#Sensor>;
49+
tree:member <sensor1>, <sensor2> .
50+
51+
<sensor1>
52+
a sosa:Sensor;
53+
sosa:madeObservation
54+
<sensor1-observation1>,
55+
<sensor1-observation2>;
56+
sosa:observes om:Temperature .
57+
58+
<sensor1-observation1>
59+
a sosa:Observation;
60+
sosa:observedProperty om:Temperature;
61+
sosa:madeBySensor <sensor1>;
62+
sosa:hasResult <result1>;
63+
sosa:resultTime "2020-08-25T07:05:31Z"^^xsd:dateTime .
64+
65+
<result1> a om:Measure;
66+
om:hasValue "22"^^xsd:float;
67+
om:hasUnit om:degreeCelsius .
68+
69+
<sensor1-observation2>
70+
a sosa:Observation;
71+
sosa:observedProperty om:Temperature;
72+
sosa:madeBySensor <sensor1>;
73+
sosa:hasResult <result2>;
74+
sosa:resultTime "2020-08-25T07:05:32Z"^^xsd:dateTime .
75+
76+
<result2> a om:Measure;
77+
om:hasValue "22"^^xsd:float;
78+
om:hasUnit om:degreeCelsius .
79+
80+
<sensor2>
81+
a sosa:Sensor;
82+
sosa:observes om:Temperature .
83+
```
84+
85+
And its corresponding ShEx file (called Sensor.shex)
86+
87+
```shex
88+
PREFIX sosa: <http://www.w3.org/ns/sosa/>
89+
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
90+
PREFIX om: <http://www.ontology-of-units-of-measure.org/resource/om-2/>
91+
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
92+
93+
<#Sensor> {
94+
a [sosa:Sensor] ;
95+
sosa:observes [om:Temperature] ;
96+
sosa:madeObservation @<#TemperatureObservation> *
97+
}
98+
99+
<#TemperatureObservation> {
100+
a [sosa:Observation] ;
101+
sosa:resultTime xsd:dateTime ;
102+
sosa:madeBySensor @<#Sensor> ? ;
103+
sosa:observedProperty [om:Temperature];
104+
sosa:hasResult @<#TemperatureResult>
105+
}
106+
107+
<#TemperatureResult> {
108+
a [om:Measure];
109+
om:hasValue xsd:float ;
110+
om:hasUnit [om:degreeCelsius]
111+
}
112+
```
113+
</div>

0 commit comments

Comments
 (0)