Add date modified/imported

[jeff-zucker]

The information about when records were modified is currently stored using the ex:modified predicate in a resource's record. This is temporary until we can create a more robust system in which the modified date refers to the record itself, not to the subject of the record.

Rather than lose the information about what was added to the dataset and when, I suggest we go with keeping the modified and imported date-time stamps in the resource record only temporarily. I'll then come up with a "catalog-record" shape that is not part of the resource record and move the dates to that when its ready. The metadata will then describe the record but not be a part of the record itself so the metadata will refer to the modification of the record not to the modification of the person or resource the record describes.

Here's how DCAT does it, I suggest we follow it :

[elf-pavlik]

This may be a good candidate to take advantage of a constraint that uses predicate in a reverse direction, for example

shape :EventShape -> ex:Event ;
	sh:name "Event"@en {
	ex:name xsd:string|rdf:langString [1..1] %
		sh:name "name"@en
	% .
	^foaf:primaryTopic IRI  [1..1] dcat:CatalogRecord %
		sh:name "is the primary topic of"@en ;
		sh:description "catalog record for this resource"
	% .
	# ...
}

Since we want to have it for all the records we probably want to define it on a base shape and have all the shapes extending that base shape.

@jeswr did I use that ^ for an inverse correctly? I also don't know syntax for shapes extending a base shape, could you please give us an example?

It isn't problem of a catalog but LDO still doesn't support @reverse as far as I can remember, no dedicated issue there yet just this comment.

• Allow passing custom JSON-LD context mappings to @ldo/cli o-development/ldo#47 (comment)

[jeff-zucker]

Do we need the reverse? Why not just do what DCAT does and link from the catalog-record to the resource and not include it in the resource at all?

If we do need it, there is foaf:primaryTopicOf - would SHACL be able to use that to validate?

[jeswr]

@jeswr did I use that ^ for an inverse correctly?

Yes SHACLC path syntax is identical to SPARQL

I also don't know syntax for shapes extending a base shape, could you please give us an example?

You need to use sh:and - there is a good example in the definition on the spec document

[elf-pavlik]

Do we need the reverse? Why not just do what DCAT does and link from the catalog-record to the resource and not include it in the resource at all?

Currently we have one big directed labeled graph, all the statements are in the same document. By saying 'in the resource' do you mean adding a constraint to the shape we use to validate the resource? If we want to require that each 'solid resource' needs to have a 'catalog record', I think we need to ensure that when we validate the resource.

If we do need it, there is foaf:primaryTopicOf - would SHACL be able to use that to validate?

I guess we could use that, at the same time if there is anything using the data that relies on foaf:primaryTopic, it would either need to run a reasoner or we would need to run reasoner before publishing and materialize those inferences.
Personally I don't think avoiding the use of properties in reverse direction justifies depending on a reasoner. I think @jeswr is the best person to guide us here.

[elf-pavlik]

While I think it is useful to get it working in the long run. I would personally prefer to focus on interlinking existing records without waiting to get dcat:CatalogRecord with modfified/imported in place.

Currently we can rely on git history to see who changed what and when, which is much more reliable for auditing than those two vague timestamps.