triplify.org - vocabulary/update

2008-08-01 00:26:22

Comparison for /vocabulary / update of 2008-08-01 00:26:22 and 2008-08-01 13:48:21

Additions:

http://example.com/lod/update/2008/Jan/01/17/58/06/user123 update:updatedResource http://example.com/lod/users/JohnDoe .
http://example.com/lod/update/2008/Jan/01/17/58/06/user123 update:updatedAt "20080101T17:58:06"^<xsd:dateTime> .
http://example.com/lod/update/2008/Jan/01/17/58/06/user123 update:updatedBy http://example.com/lod/users/JohnDoe .
Individual updates are identified by a sequential identifier (i.e. “user123” in the example). Arbitrary meta data can be attached to these updates, such as the time of the update (probably redundant since that can be inferred from the URL) or a certain person who performed the update.
Triplify automatically generates all the resources in the update URI space, when the Triplify configuration $triplify['queries'] contains a query named update. This query has to return at least two columns. The first column contains the date when to update occurred, the second column contains the id of the updated resource. An example is given below:

Deletions:

http://example.com/lod/update/2008/Jan/01/17/58/06/123 update:updatedResource http://example.com/lod/users/JohnDoe .
http://example.com/lod/update/2008/Jan/01/17/58/06/123 update:updatedAt "20080101T00:00:01"^<xsd:dateTime> .
http://example.com/lod/update/2008/Jan/01/17/58/06/123 update:updatedBy http://example.com/lod/users/JohnDoe .
Individual updates are identified by a sequential number (i.e. “123” in the example). Arbitrary meta data can be attached to these updates, such as the time of the update (probably redundant since that can be inferred from the URL) or a certain person who performed the update.
Triplify automatically generates all the resources in the update URI space, when the Triplify configuration $triplify['queries'] contains a query update. This query has to return at least two columns. The first column contains the date when to update occured, the second column contains the id of the updated resource. An example is given below:

2008-08-01 00:25:26

Comparison for /vocabulary / update of 2008-08-01 00:25:26 and 2008-08-01 00:26:22

No differences.

2008-07-31 23:23:04

Comparison for /vocabulary / update of 2008-07-31 23:23:04 and 2008-08-01 00:25:26

Additions:

The approach: Linked Data Update Logs

Example

The workings of the Triplify Linked Data Update Logs can be observed with Triplify's own datasource registry:
http://triplify.org/triplify/update/

Deletions:

The approach: Standardized Linked Data Update Logs

2008-07-31 23:22:42

Comparison for /vocabulary / update of 2008-07-31 23:22:42 and 2008-07-31 23:23:04

Additions:

SELECT p.changed AS id,p.id AS 'update:updatedResource->project' FROM project p

Deletions:

SELECT p.changed AS id,p.id AS 'update:updatedResource->project' FROM project p"

2008-07-31 23:21:37

Comparison for /vocabulary / update of 2008-07-31 23:21:37 and 2008-07-31 23:22:42

Additions:

Triplify automatically generates all the resources in the update URI space, when the Triplify configuration $triplify['queries'] contains a query update. This query has to return at least two columns. The first column contains the date when to update occured, the second column contains the id of the updated resource. An example is given below:

SELECT p.changed AS id,p.id AS 'update:updatedResource->project' FROM project p"

Deletions:

Triplify automatically generates all the resources in the update URI space, when the Triplify configuration $triplify['queries'] contains a query update. This query has to return at least two columns. The first column contains the data when to update occured, the second column contains the id of the updated resource. An example is given below:

SELECT p.changed AS id,p.id AS 'update:updatedResource->project' FROM project p"

2008-07-31 22:18:18

Comparison for /vocabulary / update of 2008-07-31 22:18:18 and 2008-07-31 23:21:37

Additions:

Invocation

Triplify automatically generates all the resources in the update URI space, when the Triplify configuration $triplify['queries'] contains a query update. This query has to return at least two columns. The first column contains the data when to update occured, the second column contains the id of the updated resource. An example is given below:

SELECT p.changed AS id,p.id AS 'update:updatedResource->project' FROM project p"

2008-07-31 22:16:53

Comparison for /vocabulary / update of 2008-07-31 22:16:53 and 2008-07-31 22:18:18

Additions:

SubClassOf: update:Update
Type: ObjectProperty
Type: DatatypeProperty

Deletions:

Sub Class Of: update:Update
Type: Object Property
Type: Datatype Property

2008-07-31 22:06:15

Comparison for /vocabulary / update of 2008-07-31 22:06:15 and 2008-07-31 22:16:53

Additions:

To have a centralized registry (such as e.g. implemented by PingTheSemanticWeb service) does not seem to be feasible when Linked Data becomes more popular – think of millions of Linked Data endpoints pinging such a registry each time a small change occurred.
This nesting could continue until we finally reach an URL, which exposes all updates performed in a certain second in time. For very frequently updated LOD endpoints (e.g. Wikipedia) this interval of one second will be sufficiently small enough, so the related update information can be still easily retrieved. For rarely updated LOD endpoints (e.g. a personal Weblog) links should only point to non-empty Update Collections in order to prevent crawlers from performing unnecessary HTTP requests.

update:Deletion

Sub Class Of: update:Update
Represents the deletion of an RDF resource.
Type: Object Property
Domain: update:Update
Points to the resource which was updated.
Type: Datatype Property
Domain: update:Update
Range: xsd:dateTime
Refers to the date and time when a certain update occurred.
Type: Property
Domain: update:Update
Points to the user description who performed the update.

Deletions:

To have a centralized registry (such as e.g. implemented by PingTheSemanticWeb service) does not seem to be feasible when Linked Data becomes more popular – think of millions of Linked Data endpoints pinging such a registry each time a small change occured.
This nesting could continue until we finally reach a URL, which exposes all updates performed in a certain second in time. For very frequently updated LOD endpoints (e.g. Wikipedia) this interval of one second will be sufficiently small enough, so the related update information can be still easily retrieved. For rarely updated LOD endpoints (e.g. a personal Weblog) links should only point to non-empty Update Collections in order to prevent crawlers from performing unnecessary HTTP requests.

2008-07-31 22:05:24

Comparison for /vocabulary / update of 2008-07-31 22:05:24 and 2008-07-31 22:06:15

Additions:

Deletions: