diff --git a/assets/contexts/nexus/core/shacl20170720/context.json b/assets/contexts/nexus/core/shacl20170720/context.json index 74e465b0..145885e9 100755 --- a/assets/contexts/nexus/core/shacl20170720/context.json +++ b/assets/contexts/nexus/core/shacl20170720/context.json @@ -10,7 +10,7 @@ "shsh": "http://www.w3.org/ns/shacl-shacl#", "dcterms": "http://purl.org/dc/terms/", "schema": "http://schema.org/", - "nxv": "https://bbp-nexus.epfl.ch/vocabs/nexus/core/terms/v0.1.0/", + "nxv": "https://bluebrain.github.io/nexus/vocabulary/", "shext": "http://www.w3.org/ns/shacl/ext#", "class": { "@id": "sh:class", diff --git a/assets/contexts/nexus/core/shacl20170720/prefixmapings.html b/assets/contexts/nexus/core/shacl20170720/prefixmapings.html index 420e821e..c1ae9b75 100644 --- a/assets/contexts/nexus/core/shacl20170720/prefixmapings.html +++ b/assets/contexts/nexus/core/shacl20170720/prefixmapings.html @@ -141,7 +141,7 @@ @@ -217,7 +217,7 @@
-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/assets/provtemplates/README.html b/assets/provtemplates/README.html index b400a288..68a2e874 100644 --- a/assets/provtemplates/README.html +++ b/assets/provtemplates/README.html @@ -143,7 +143,7 @@ @@ -162,7 +162,7 @@

<
-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/contexts/data.json b/contexts/data.json index 99550313..100ec8f5 100644 --- a/contexts/data.json +++ b/contexts/data.json @@ -1,32 +1,29 @@ { "@context": { "@vocab": "https://neuroshapes.org/", - "ExperimentalActivity": { - "@id": "nsg:ExperimentalActivity" - }, - "BrainParcellationMesh": { - "@id": "nsg:BrainParcellationMesh" + "StimulusExperiment": { + "@id": "nsg:StimulusExperiment" }, - "LabeledCell": { - "@id": "nsg:LabeledCell" + "ValidationResult": { + "@id": "nsg:ValidationResult" }, - "Derivation": { - "@id": "prov:Derivation" + "QuantitativeValue": { + "@id": "schema:QuantitativeValue" }, - "Person": { - "@id": "schema:Person" + "EmodelFeatureGeneration": { + "@id": "nsg:EmodelFeatureGeneration" }, - "ParcellationImageData": { - "@id": "nsg:ParcellationImageData" + "IntraCellularSharpElectrodeRecordedSlice": { + "@id": "nsg:IntraCellularSharpElectrodeRecordedSlice" }, - "TemplateVolume": { - "@id": "nsg:TemplateVolume" + "DeformableTransform": { + "@id": "nsg:DeformableTransform" }, - "ETypeFeatureProtocol": { - "@id": "nsg:ETypeFeatureProtocol" + "Transform": { + "@id": "nsg:Transform" }, - "ReconstructedWholeBrainCell": { - "@id": "nsg:ReconstructedWholeBrainCell" + "Usage": { + "@id": "prov:Usage" }, "ReconstructedNeuronMorphology": { "@id": "nsg:ReconstructedNeuronMorphology" @@ -34,224 +31,224 @@ "ReconstructedCell": { "@id": "nsg:ReconstructedCell" }, - "ReconstructedCellRelease": { - "@id": "nsg:ReconstructedCellRelease" + "MEModelRelease": { + "@id": "nsg:MEModelRelease" }, - "DataDownload": { - "@id": "schema:DataDownload" + "Concept": { + "@id": "skos:Concept" }, - "AtlasRelease": { - "@id": "nsg:AtlasRelease" + "Class": { + "@id": "owl:Class" }, - "BrainAtlasRelease": { - "@id": "nsg:BrainAtlasRelease" + "ReconstructedCellFormatConversion": { + "@id": "nsg:ReconstructedCellFormatConversion" }, - "Invalidation": { - "@id": "prov:Invalidation" + "ModelRelease": { + "@id": "nsg:ModelRelease" }, - "Annotation": { - "@id": "nsg:Annotation" + "IonChannelMechanismRelease": { + "@id": "nsg:IonChannelMechanismRelease" }, - "BoundingBox": { - "@id": "nsg:BoundingBox" + "RegionOfInterest": { + "@id": "nsg:RegionOfInterest" }, - "QuantitativeValue": { - "@id": "schema:QuantitativeValue" + "IntraCellularSharpElectrode": { + "@id": "nsg:IntraCellularSharpElectrode" }, - "IonChannelGene": { - "@id": "nsg:IonChannelGene" + "MorphologyMeshGeneration": { + "@id": "nsg:MorphologyMeshGeneration" }, - "SimplifiedCircuit": { - "@id": "nsg:SimplifiedCircuit" + "ExperimentalProtocol": { + "@id": "nsg:ExperimentalProtocol" }, - "OntologyConversion": { - "@id": "nsg:OntologyConversion" + "Analysis": { + "@id": "nsg:Analysis" }, - "MEModel": { - "@id": "nsg:MEModel" + "EdgeCollection": { + "@id": "nsg:EdgeCollection" }, - "EmodelFeatureGeneration": { - "@id": "nsg:EmodelFeatureGeneration" + "SubCellularModelScript": { + "@id": "nsg:SubCellularModelScript" }, - "FixedStainedSlice": { - "@id": "nsg:FixedStainedSlice" + "EmptyCollection": { + "@id": "prov:EmptyCollection" }, - "AnnotatedSlice": { - "@id": "nsg:AnnotatedSlice" + "TemplateReconstruction": { + "@id": "nsg:TemplateReconstruction" }, - "MorphologyMesh": { - "@id": "nsg:MorphologyMesh" + "OntologyConversion": { + "@id": "nsg:OntologyConversion" }, - "MorphologyMeshGeneration": { - "@id": "nsg:MorphologyMeshGeneration" + "Trace": { + "@id": "nsg:Trace" }, - "IntraCellularSharpElectrodeRecordedSlice": { - "@id": "nsg:IntraCellularSharpElectrodeRecordedSlice" + "InVitroSliceWholeCellPatchClampElectrophysiologyTrace": { + "@id": "nsg:InVitroSliceWholeCellPatchClampElectrophysiologyTrace" }, - "Threshold": { - "@id": "nsg:Threshold" + "WholeCellPatchClamp": { + "@id": "nsg:WholeCellPatchClamp" }, - "ValidationResult": { - "@id": "nsg:ValidationResult" + "Reconstruction": { + "@id": "nsg:Reconstruction" }, - "Generation": { - "@id": "prov:Generation" + "NeuronMorphologyReconstruction": { + "@id": "nsg:NeuronMorphologyReconstruction" }, - "MorphologyRelease": { - "@id": "nsg:MorphologyRelease" + "Derivation": { + "@id": "prov:Derivation" + }, + "EModelRelease": { + "@id": "nsg:EModelRelease" }, "geometryParameter": { "@id": "nsg:geometryParameter" }, - "TraceGeneration": { - "@id": "nsg:TraceGeneration" + "ReconstructedCellRelease": { + "@id": "nsg:ReconstructedCellRelease" }, - "EModelRelease": { - "@id": "nsg:EModelRelease" + "Organization": { + "@id": "schema:Organization" }, - "ReconstructedCellReleaseGeneration": { - "@id": "nsg:ReconstructedCellReleaseGeneration" + "InVitroWholeBrainReconstructedNeuronMorphology": { + "@id": "nsg:InVitroWholeBrainReconstructedNeuronMorphology" }, - "BrainLocation": { - "@id": "nsg:BrainLocation" + "ReconstructedWholeBrainCell": { + "@id": "nsg:ReconstructedWholeBrainCell" }, - "Ontology": { - "@id": "owl:Ontology" + "FixedStainedSlice": { + "@id": "nsg:FixedStainedSlice" }, - "PatchedCell": { - "@id": "nsg:PatchedCell" + "MorphologyMesh": { + "@id": "nsg:MorphologyMesh" }, - "ReconstructedPatchedCell": { - "@id": "nsg:ReconstructedPatchedCell" + "AtlasConstruction": { + "@id": "nsg:AtlasConstruction" }, - "IntraCellularSharpElectrodeRecordedCellCollection": { - "@id": "nsg:IntraCellularSharpElectrodeRecordedCellCollection" + "geometry": { + "@id": "nsg:geometry" }, - "Simulation": { - "@id": "nsg:Simulation" + "ParcellationImageData": { + "@id": "nsg:ParcellationImageData" }, - "BrainImaging": { - "@id": "nsg:BrainImaging" + "Morphology": { + "@id": "nsg:Morphology" }, - "VariableReport": { - "@id": "nsg:VariableReport" + "BrainAtlasRelease": { + "@id": "nsg:BrainAtlasRelease" }, - "AnalysisResult": { - "@id": "nsg:AnalysisResult" + "AtlasRelease": { + "@id": "nsg:AtlasRelease" }, - "SubCellularModel": { - "@id": "nsg:SubCellularModel" + "ImageVolume": { + "@id": "nsg:ImageVolume" }, - "Entity": { - "@id": "prov:Entity" + "ParcellationVolume": { + "@id": "nsg:ParcellationVolume" }, - "Dataset": { - "@id": "schema:Dataset" + "ParcellationOntology": { + "@id": "nsg:ParcellationOntology" }, - "SliceCollection": { - "@id": "nsg:SliceCollection" + "EModelBuilding": { + "@id": "nsg:EModelBuilding" }, - "BrainSlicing": { - "@id": "nsg:BrainSlicing" + "ExperimentalActivity": { + "@id": "nsg:ExperimentalActivity" }, - "Target": { - "@id": "nsg:Target" + "BrainLocation": { + "@id": "nsg:BrainLocation" + }, + "MorphologyDiversification": { + "@id": "nsg:MorphologyDiversification" + }, + "Annotation": { + "@id": "nsg:Annotation" }, "PatchClamp": { "@id": "nsg:PatchClamp" }, - "RotationalMatrix": { - "@id": "nsg:RotationalMatrix" + "TraceGeneration": { + "@id": "nsg:TraceGeneration" }, - "EmptyCollection": { - "@id": "prov:EmptyCollection" + "PatchedSlice": { + "@id": "nsg:PatchedSlice" }, - "RegionOfInterest": { - "@id": "nsg:RegionOfInterest" + "PatchedCellCollection": { + "@id": "nsg:PatchedCellCollection" }, - "Collection": { - "@id": "prov:Collection" + "AnalysisResult": { + "@id": "nsg:AnalysisResult" }, - "DetailedCircuit": { - "@id": "nsg:DetailedCircuit" + "TraceFeatureExtraction": { + "@id": "nsg:TraceFeatureExtraction" }, - "ApicalAnnotation": { - "@id": "nsg:ApicalAnnotation" + "TraceFeature": { + "@id": "nsg:TraceFeature" }, - "Reconstruction": { - "@id": "nsg:Reconstruction" + "Protocol": { + "@id": "nsg:Protocol" }, - "NeuronMorphologyReconstruction": { - "@id": "nsg:NeuronMorphologyReconstruction" + "Cell": { + "@id": "nsg:Cell" }, - "BrainAtlasSpatialReferenceSystem": { - "@id": "nsg:BrainAtlasSpatialReferenceSystem" + "ReconstructedCellReleaseGeneration": { + "@id": "nsg:ReconstructedCellReleaseGeneration" }, - "AtlasSpatialReferenceSystem": { - "@id": "nsg:AtlasSpatialReferenceSystem" + "ModelInstance": { + "@id": "nsg:ModelInstance" }, - "TemplateReconstruction": { - "@id": "nsg:TemplateReconstruction" + "SliceCollection": { + "@id": "nsg:SliceCollection" }, - "AcquisitionAnnotation": { - "@id": "nsg:AcquisitionAnnotation" + "ParcellationReconstruction": { + "@id": "nsg:ParcellationReconstruction" }, - "geometry": { - "@id": "nsg:geometry" + "TemplateVolume": { + "@id": "nsg:TemplateVolume" }, - "Usage": { - "@id": "prov:Usage" - }, - "LabeledCellCollection": { - "@id": "nsg:LabeledCellCollection" + "CircuitCellProperties": { + "@id": "nsg:CircuitCellProperties" }, - "Cell": { - "@id": "nsg:Cell" + "LabeledCell": { + "@id": "nsg:LabeledCell" }, - "Class": { - "@id": "owl:Class" + "Subject": { + "@id": "nsg:Subject" }, - "Concept": { - "@id": "skos:Concept" + "Slice": { + "@id": "nsg:Slice" }, - "ReconstructionCorrection": { - "@id": "nsg:ReconstructionCorrection" + "MorphologyRelease": { + "@id": "nsg:MorphologyRelease" }, - "ReconstructedCellFormatConversion": { - "@id": "nsg:ReconstructedCellFormatConversion" + "Generation": { + "@id": "prov:Generation" }, - "voxelResolution": { - "@id": "nsg:voxelResolution" + "Configuration": { + "@id": "nsg:Configuration" }, - "PatchedSlice": { - "@id": "nsg:PatchedSlice" + "BrainParcellationMesh": { + "@id": "nsg:BrainParcellationMesh" }, - "ParcellationMeshGeneration": { - "@id": "nsg:ParcellationMeshGeneration" + "Ontology": { + "@id": "owl:Ontology" }, - "TraceFeatureExtraction": { - "@id": "nsg:TraceFeatureExtraction" + "CellPlacement": { + "@id": "nsg:CellPlacement" }, - "SubjectCollection": { - "@id": "nsg:SubjectCollection" + "SynapseRelease": { + "@id": "nsg:SynapseRelease" }, "TemplateImageData": { "@id": "nsg:TemplateImageData" }, - "IntraCellularSharpElectrodeRecordedCell": { - "@id": "nsg:IntraCellularSharpElectrodeRecordedCell" - }, - "EModelBuilding": { - "@id": "nsg:EModelBuilding" - }, - "MEModelRelease": { - "@id": "nsg:MEModelRelease" + "MEModel": { + "@id": "nsg:MEModel" }, - "NISSLImageDataLayer": { - "@id": "nsg:NISSLImageDataLayer" + "SimplifiedCircuit": { + "@id": "nsg:SimplifiedCircuit" }, - "VolumetricDataLayer": { - "@id": "nsg:VolumetricDataLayer" + "MorphologyOrientationDataLayer": { + "@id": "nsg:MorphologyOrientationDataLayer" }, "BrainParcellationDataLayer": { "@id": "nsg:BrainParcellationDataLayer" @@ -259,125 +256,101 @@ "CellDensityDataLayer": { "@id": "nsg:CellDensityDataLayer" }, + "VolumetricDataLayer": { + "@id": "nsg:VolumetricDataLayer" + }, "PHDataLayer": { "@id": "nsg:PHDataLayer" }, + "NISSLImageDataLayer": { + "@id": "nsg:NISSLImageDataLayer" + }, "TwoPhotonImageDataLayer": { "@id": "nsg:TwoPhotonImageDataLayer" }, - "MorphologyOrientationDataLayer": { - "@id": "nsg:MorphologyOrientationDataLayer" - }, - "ConceptScheme": { - "@id": "skos:ConceptScheme" - }, - "ModelInstance": { - "@id": "nsg:ModelInstance" - }, - "IonChannelMechanismRelease": { - "@id": "nsg:IonChannelMechanismRelease" - }, - "Trace": { - "@id": "nsg:Trace" - }, - "SpatialIndexDerivation": { - "@id": "nsg:SpatialIndexDerivation" - }, - "Agent": { - "@id": "prov:Agent" - }, - "Analysis": { - "@id": "nsg:Analysis" + "FixationStainingMounting": { + "@id": "nsg:FixationStainingMounting" }, - "StimulusExperiment": { - "@id": "nsg:StimulusExperiment" + "ModelReleaseIndex": { + "@id": "nsg:ModelReleaseIndex" }, - "ParcellationLabel": { - "@id": "nsg:ParcellationLabel" + "IntraCellularSharpElectrodeRecordedCell": { + "@id": "nsg:IntraCellularSharpElectrodeRecordedCell" }, - "InVitroWholeBrainReconstructedNeuronMorphology": { - "@id": "nsg:InVitroWholeBrainReconstructedNeuronMorphology" + "Collection": { + "@id": "prov:Collection" }, - "EModelScript": { - "@id": "nsg:EModelScript" + "DataDownload": { + "@id": "schema:DataDownload" }, - "Transform": { - "@id": "nsg:Transform" + "BoundingBox": { + "@id": "nsg:BoundingBox" }, - "Contribution": { - "@id": "nsg:Contribution" + "Entity": { + "@id": "prov:Entity" }, - "Configuration": { - "@id": "nsg:Configuration" + "Activity": { + "@id": "prov:Activity" }, - "Transformation": { - "@id": "nsg:Transformation" + "IonChannelGene": { + "@id": "nsg:IonChannelGene" }, - "ReconstructionFromImage": { - "@id": "nsg:ReconstructionFromImage" + "ReconstructedPatchedCell": { + "@id": "nsg:ReconstructedPatchedCell" }, "TraceCollection": { "@id": "nsg:TraceCollection" }, - "SpatialIndex": { - "@id": "nsg:SpatialIndex" - }, - "ModelValidation": { - "@id": "nsg:ModelValidation" - }, - "ImageVolume": { - "@id": "nsg:ImageVolume" - }, - "ModelReleaseIndex": { - "@id": "nsg:ModelReleaseIndex" + "ParcellationMeshGeneration": { + "@id": "nsg:ParcellationMeshGeneration" }, - "DeformableTransform": { - "@id": "nsg:DeformableTransform" + "Invalidation": { + "@id": "prov:Invalidation" }, - "HostCell": { - "@id": "nsg:HostCell" + "PatchedCell": { + "@id": "nsg:PatchedCell" }, - "Protocol": { - "@id": "nsg:Protocol" + "ReconstructedCellReleaseProcess": { + "@id": "nsg:ReconstructedCellReleaseProcess" }, - "Subject": { - "@id": "nsg:Subject" + "RotationalMatrix": { + "@id": "nsg:RotationalMatrix" }, - "SubCellularModelScript": { - "@id": "nsg:SubCellularModelScript" + "ImageStack": { + "@id": "nsg:ImageStack" }, - "SingleCellSimulationTrace": { - "@id": "nsg:SingleCellSimulationTrace" + "Contribution": { + "@id": "nsg:Contribution" }, - "WholeCellPatchClamp": { - "@id": "nsg:WholeCellPatchClamp" + "AnnotatedSlice": { + "@id": "nsg:AnnotatedSlice" }, - "ParcellationReconstruction": { - "@id": "nsg:ParcellationReconstruction" + "ReconstructionFromImage": { + "@id": "nsg:ReconstructionFromImage" }, - "TraceFeature": { - "@id": "nsg:TraceFeature" + "Person": { + "@id": "schema:Person" }, - "SoftwareAgent": { - "@id": "prov:SoftwareAgent" + "BrainSlicing": { + "@id": "nsg:BrainSlicing" }, - "ExperimentalProtocol": { - "@id": "nsg:ExperimentalProtocol" + "SubjectCollection": { + "@id": "nsg:SubjectCollection" }, - "NodeCollection": { - "@id": "nsg:NodeCollection" + "Dataset": { + "@id": "schema:Dataset" }, - "EModel": { - "@id": "nsg:EModel" + "Simulation": { + "@id": "nsg:Simulation" }, - "ReconstructedCellReleaseProcess": { - "@id": "nsg:ReconstructedCellReleaseProcess" + "Agent": { + "@id": "prov:Agent" }, - "SynapseRelease": { - "@id": "nsg:SynapseRelease" + "SubCellularModel": { + "@id": "nsg:SubCellularModel" }, - "AffineLinearTransform": { - "@id": "nsg:AffineLinearTransform" + "ApicalAnnotation": { + "@id": "nsg:ApicalAnnotation" }, "LinearTransform": { "@id": "nsg:LinearTransform" @@ -385,837 +358,880 @@ "RigidLinearTransform": { "@id": "nsg:RigidLinearTransform" }, - "ParcellationVolume": { - "@id": "nsg:ParcellationVolume" - }, - "IntraCellularSharpElectrode": { - "@id": "nsg:IntraCellularSharpElectrode" - }, - "CellPlacement": { - "@id": "nsg:CellPlacement" + "AffineLinearTransform": { + "@id": "nsg:AffineLinearTransform" }, - "Morphology": { - "@id": "nsg:Morphology" + "BrainImaging": { + "@id": "nsg:BrainImaging" }, - "MorphologyDiversification": { - "@id": "nsg:MorphologyDiversification" + "Target": { + "@id": "nsg:Target" }, - "EdgeCollection": { - "@id": "nsg:EdgeCollection" + "SpatialIndex": { + "@id": "nsg:SpatialIndex" }, "BluePyEfeFeatures": { "@id": "nsg:BluePyEfeFeatures" }, - "InVitroSliceReconstructedPatchedNeuron": { - "@id": "nsg:InVitroSliceReconstructedPatchedNeuron" + "Threshold": { + "@id": "nsg:Threshold" }, - "Transfection": { - "@id": "nsg:Transfection" + "VariableReport": { + "@id": "nsg:VariableReport" }, - "Slice": { - "@id": "nsg:Slice" + "DetailedCircuit": { + "@id": "nsg:DetailedCircuit" }, - "Organization": { - "@id": "schema:Organization" + "SoftwareAgent": { + "@id": "prov:SoftwareAgent" }, - "ImageStack": { - "@id": "nsg:ImageStack" + "SpatialIndexDerivation": { + "@id": "nsg:SpatialIndexDerivation" }, - "ModelRelease": { - "@id": "nsg:ModelRelease" + "Transfection": { + "@id": "nsg:Transfection" }, - "CircuitCellProperties": { - "@id": "nsg:CircuitCellProperties" + "IntraCellularSharpElectrodeRecordedCellCollection": { + "@id": "nsg:IntraCellularSharpElectrodeRecordedCellCollection" }, - "InVitroSliceWholeCellPatchClampElectrophysiologyTrace": { - "@id": "nsg:InVitroSliceWholeCellPatchClampElectrophysiologyTrace" + "AcquisitionAnnotation": { + "@id": "nsg:AcquisitionAnnotation" }, - "ParcellationOntology": { - "@id": "nsg:ParcellationOntology" + "ConceptScheme": { + "@id": "skos:ConceptScheme" }, - "PatchedCellCollection": { - "@id": "nsg:PatchedCellCollection" + "ModelValidation": { + "@id": "nsg:ModelValidation" + }, + "voxelResolution": { + "@id": "nsg:voxelResolution" }, "SingleCellTraceGeneration": { "@id": "nsg:SingleCellTraceGeneration" }, - "AtlasConstruction": { - "@id": "nsg:AtlasConstruction" + "ParcellationLabel": { + "@id": "nsg:ParcellationLabel" }, - "Activity": { - "@id": "prov:Activity" + "EModel": { + "@id": "nsg:EModel" }, - "FixationStainingMounting": { - "@id": "nsg:FixationStainingMounting" + "HostCell": { + "@id": "nsg:HostCell" }, - "generated": { - "@id": "prov:generated" + "SingleCellSimulationTrace": { + "@id": "nsg:SingleCellSimulationTrace" }, - "distribution": { - "@id": "schema:distribution" + "InVitroSliceReconstructedPatchedNeuron": { + "@id": "nsg:InVitroSliceReconstructedPatchedNeuron" }, - "brainRegion": { - "@id": "nsg:brainRegion" + "ETypeFeatureProtocol": { + "@id": "nsg:ETypeFeatureProtocol" }, - "name": { - "@id": "schema:name" + "LabeledCellCollection": { + "@id": "nsg:LabeledCellCollection" }, - "language": { - "@id": "schema:language" + "BrainAtlasSpatialReferenceSystem": { + "@id": "nsg:BrainAtlasSpatialReferenceSystem" }, - "contentUrl": { - "@id": "schema:contentUrl" + "AtlasSpatialReferenceSystem": { + "@id": "nsg:AtlasSpatialReferenceSystem" }, - "digest": { - "@id": "nsg:digest" + "Transformation": { + "@id": "nsg:Transformation" }, - "imagingMethod": { - "@id": "nsg:imagingMethod" + "EModelScript": { + "@id": "nsg:EModelScript" + }, + "ReconstructionCorrection": { + "@id": "nsg:ReconstructionCorrection" + }, + "NodeCollection": { + "@id": "nsg:NodeCollection" + }, + "mType": { + "@id": "nsg:mType" + }, + "prefLabel": { + "@id": "skos:prefLabel" + }, + "morphologyIndex": { + "@id": "nsg:morphologyIndex" + }, + "center": { + "@id": "nsg:center" + }, + "vendor": { + "@id": "nsg:vendor" + }, + "size": { + "@id": "schema:size" + }, + "target": { + "@id": "nsg:target" + }, + "spatialReferenceSystem": { + "@id": "nsg:spatialReferenceSystem" + }, + "inScheme": { + "@id": "skos:inScheme" }, "used": { "@id": "prov:used" }, + "isPartOf": { + "@id": "schema:isPartOf" + }, "valueY": { "@id": "nsg:valueY" }, - "species": { - "@id": "nsg:species" + "featureExtractionConfiguration": { + "@id": "nsg:featureExtractionConfiguration" }, - "value": { - "@id": "schema:value" + "wasRevisionOf": { + "@id": "prov:wasRevisionOf" }, - "hasSelector": { - "@id": "nsg:hasSelector" + "thirdRow": { + "@id": "nsg:thirdRow" }, - "secondRow": { - "@id": "nsg:secondRow" + "entity": { + "@id": "prov:entity" }, - "hypampThreshold": { - "@id": "nsg:hypampThreshold" + "value": { + "@id": "schema:value" }, - "analogToDigitalConverter": { - "@id": "nsg:analogToDigitalConverter" + "activity": { + "@id": "prov:activity" }, - "sliceWidth": { - "@id": "nsg:sliceWidth" + "image": { + "@id": "schema:image" }, - "hadMember": { - "@id": "prov:hadMember" + "stimulus": { + "@id": "nsg:stimulus" }, - "valueZ": { - "@id": "nsg:valueZ" + "brainLocation": { + "@id": "nsg:brainLocation" }, - "valueX": { - "@id": "nsg:valueX" + "synapseRelease": { + "@id": "nsg:synapseRelease" }, - "spatialIndex": { - "@id": "nsg:spatialIndex" + "qualifiedGeneration": { + "@id": "prov:qualifiedGeneration" }, - "synapse": { - "@id": "nsg:synapse" + "repetition": { + "@id": "nsg:repetition" }, - "wasAttributedTo": { - "@id": "prov:wasAttributedTo" + "distribution": { + "@id": "schema:distribution" }, - "location": { - "@id": "nsg:location" + "radius": { + "@id": "nsg:radius" }, - "inScheme": { - "@id": "skos:inScheme" + "digitalToAnalogConverter": { + "@id": "nsg:digitalToAnalogConverter" }, - "imageModality": { - "@id": "nsg:imageModality" + "reagentMolarWeight": { + "@id": "nsg:reagentMolarWeight" }, - "wasDerivedFrom": { - "@id": "prov:wasDerivedFrom" + "imports": { + "@id": "owl:imports" }, - "conformsTo": { - "@id": "nsg:conformsTo" + "identifier": { + "@id": "schema:identifier" }, - "atTime": { - "@id": "prov:atTime" + "generated": { + "@id": "prov:generated" }, - "chlorideReversalPotential": { - "@id": "nsg:chlorideReversalPotential" + "nodeCollection": { + "@id": "nsg:nodeCollection" }, - "deathDate": { - "@id": "schema:deathDate" + "description": { + "@id": "schema:description" }, - "propertyID": { - "@id": "schema:propertyID" + "hasPart": { + "@id": "schema:hasPart" }, - "affiliation": { - "@id": "schema:affiliation" + "imageOrigin": { + "@id": "nsg:imageOrigin" }, - "url": { - "@id": "schema:url" + "addressCountry": { + "@id": "schema:addressCountry" }, - "wasGeneratedBy": { - "@id": "prov:wasGeneratedBy" + "eType": { + "@id": "nsg:eType" }, - "hadProtocol": { - "@id": "nsg:hadProtocol" + "hadMember": { + "@id": "prov:hadMember" }, - "endedAtTime": { - "@id": "prov:endedAtTime" + "solution": { + "@id": "nsg:solution" }, - "alternateName": { - "@id": "schema:alternateName" + "targetHoldingPotential": { + "@id": "nsg:targetHoldingPotential" }, - "circuitCellProperties": { - "@id": "nsg:circuitCellProperties" + "sku": { + "@id": "schema:sku" }, - "materials": { - "@id": "nsg:materials" + "brainRegion": { + "@id": "nsg:brainRegion" }, - "qualifiedGeneration": { - "@id": "prov:qualifiedGeneration" + "maxValue": { + "@id": "schema:maxValue" }, - "memodelRelease": { - "@id": "nsg:memodelRelease" + "liquidJunctionPotential": { + "@id": "nsg:liquidJunctionPotential" }, - "brainLocation": { - "@id": "nsg:brainLocation" + "sex": { + "@id": "nsg:sex" }, - "mType": { - "@id": "nsg:mType" + "modelScript": { + "@id": "nsg:modelScript" }, - "encodingFormat": { - "@id": "schema:encodingFormat" + "putativeEtype": { + "@id": "nsg:putativeEtype" + }, + "unitCode": { + "@id": "schema:unitCode" }, "hadRole": { "@id": "prov:hadRole" }, - "strain": { - "@id": "nsg:strain" - }, - "wasRevisionOf": { - "@id": "prov:wasRevisionOf" - }, - "source": { - "@id": "nsg:source" - }, - "disease": { - "@id": "nsg:disease" + "quality": { + "@id": "nsg:quality" }, - "unitCode": { - "@id": "schema:unitCode" + "status": { + "@id": "nsg:status" }, - "putativeMType": { - "@id": "nsg:putativeMType" + "volumeDimension": { + "@id": "nsg:volumeDimension" }, - "author": { - "@id": "schema:author" + "wasAttributedTo": { + "@id": "prov:wasAttributedTo" }, - "hasTarget": { - "@id": "nsg:hasTarget" + "slicingAngle": { + "@id": "nsg:slicingAngle" }, - "target": { - "@id": "nsg:target" + "gain": { + "@id": "nsg:gain" }, - "isRegisteredIn": { - "@id": "nsg:isRegisteredIn" + "sliceResolution": { + "@id": "nsg:sliceResolution" }, - "parcellationVolume": { - "@id": "nsg:parcellationVolume" + "warning": { + "@id": "nsg:warning" }, - "pipetteResistance": { - "@id": "nsg:pipetteResistance" + "subCellularMechanism": { + "@id": "nsg:subCellularMechanism" }, - "boundary": { - "@id": "nsg:boundary" + "version": { + "@id": "schema:version" }, - "scale": { - "@id": "nsg:scale" + "temperature": { + "@id": "nsg:temperature" }, - "modelScript": { - "@id": "nsg:modelScript" + "name": { + "@id": "schema:name" }, - "hasPart": { - "@id": "schema:hasPart" + "imagingMethod": { + "@id": "nsg:imagingMethod" }, - "center": { - "@id": "nsg:center" + "hasAxon": { + "@id": "nsg:hasAxon" }, - "endMembranePotential": { - "@id": "nsg:endMembranePotential" + "keywords": { + "@id": "schema:keywords" }, - "atlasVersion": { - "@id": "nsg:atlasVersion" + "startedAtTime": { + "@id": "prov:startedAtTime" }, - "volumeDimension": { - "@id": "nsg:volumeDimension" + "dateModified": { + "@id": "schema:dateModified" }, - "givenName": { - "@id": "schema:givenName" + "templateVolume": { + "@id": "nsg:templateVolume" }, - "hasSource": { - "@id": "nsg:hasSource" + "steps": { + "@id": "nsg:steps" }, - "nodeCollection": { - "@id": "nsg:nodeCollection" + "labelingCompound": { + "@id": "nsg:labelingCompound" }, - "activityType": { - "@id": "nsg:activityType" + "channel": { + "@id": "nsg:channel" }, - "isPartOf": { - "@id": "schema:isPartOf" + "atTime": { + "@id": "prov:atTime" }, - "objectOfStudy": { - "@id": "nsg:objectOfStudy" + "sweep": { + "@id": "nsg:sweep" }, - "bathSolution": { - "@id": "nsg:bathSolution" + "imageDirection": { + "@id": "nsg:imageDirection" }, - "datePublished": { - "@id": "schema:datePublished" + "activityType": { + "@id": "nsg:activityType" }, - "generation": { - "@id": "nsg:generation" + "circuitCellProperties": { + "@id": "nsg:circuitCellProperties" }, - "atlasSpatialReferenceSystem": { - "@id": "nsg:atlasSpatialReferenceSystem" + "fixationMethod": { + "@id": "nsg:fixationMethod" }, - "activity": { - "@id": "prov:activity" + "cellLine": { + "@id": "nsg:cellLine" }, - "cellLibraryFile": { - "@id": "nsg:cellLibraryFile" + "hasBasalDendrite": { + "@id": "nsg:hasBasalDendrite" }, - "altLabel": { - "@id": "skos:altLabel" + "boundary": { + "@id": "nsg:boundary" }, - "keywords": { - "@id": "schema:keywords" + "endMembranePotential": { + "@id": "nsg:endMembranePotential" }, - "age": { - "@id": "nsg:age" + "locationInSlice": { + "@id": "nsg:locationInSlice" }, - "license": { - "@id": "schema:license" + "hasTarget": { + "@id": "nsg:hasTarget" }, - "sku": { - "@id": "schema:sku" + "qualifiedAssociation": { + "@id": "prov:qualifiedAssociation" }, - "orientation": { - "@id": "nsg:orientation" + "ionChannelGene": { + "@id": "nsg:ionChannelGene" }, - "score": { - "@id": "nsg:score" + "species": { + "@id": "nsg:species" }, - "citation": { - "@id": "schema:citation" + "sliceInterval": { + "@id": "nsg:sliceInterval" }, - "boundingBox": { - "@id": "nsg:boundingBox" + "synapse": { + "@id": "nsg:synapse" }, "releaseDate": { "@id": "schema:releaseDate" }, - "agent": { - "@id": "prov:agent" + "deathDate": { + "@id": "schema:deathDate" }, - "eModel": { - "@id": "nsg:eModel" + "view3d": { + "@id": "nsg:view3d" }, - "morphology": { - "@id": "nsg:morphology" + "numberOfSlices": { + "@id": "nsg:numberOfSlices" }, - "seriesResistance": { - "@id": "nsg:seriesResistance" + "minValue": { + "@id": "schema:minValue" }, - "repetitions": { - "@id": "schema:repetitions" + "slicingPlane": { + "@id": "nsg:slicingPlane" }, - "diseaseModel": { - "@id": "nsg:diseaseModel" + "dateOfSurgery": { + "@id": "nsg:dateOfSurgery" }, - "identifier": { - "@id": "schema:identifier" + "origin": { + "@id": "nsg:origin" }, - "faxNumber": { - "@id": "schema:faxNumber" + "atlasVersion": { + "@id": "nsg:atlasVersion" }, - "ionChannelGene": { - "@id": "nsg:ionChannelGene" + "qualifiedUsage": { + "@id": "prov:qualifiedUsage" }, - "period": { - "@id": "nsg:period" + "electrodeResistance": { + "@id": "nsg:electrodeResistance" }, - "warning": { - "@id": "nsg:warning" + "altLabel": { + "@id": "skos:altLabel" }, - "mainModelScript": { - "@id": "nsg:mainModelScript" + "encodingFormat": { + "@id": "schema:encodingFormat" }, - "synapseRelease": { - "@id": "nsg:synapseRelease" + "upperPoint": { + "@id": "nsg:upperPoint" }, - "entity": { - "@id": "prov:entity" + "hadProtocol": { + "@id": "nsg:hadProtocol" }, - "addressLocality": { - "@id": "schema:addressLocality" + "alternateName": { + "@id": "schema:alternateName" }, - "view3d": { - "@id": "nsg:view3d" + "measuredHoldingPotential": { + "@id": "nsg:measuredHoldingPotential" }, - "hadUsage": { - "@id": "prov:hadUsage" + "experimentalCell": { + "@id": "nsg:experimentalCell" }, - "memodelIndex": { - "@id": "nsg:memodelIndex" + "label": { + "@id": "rdfs:label" }, - "treatment": { - "@id": "nsg:treatment" + "objectOfStudy": { + "@id": "nsg:objectOfStudy" }, - "bestScore": { - "@id": "nsg:bestScore" + "annotationAngle": { + "@id": "nsg:annotationAngle" }, - "distance": { - "@id": "schema:distance" + "streetAddress": { + "@id": "schema:streetAddress" }, - "firstRow": { - "@id": "nsg:firstRow" + "variable": { + "@id": "nsg:variable" }, - "index": { - "@id": "nsg:index" + "isRegisteredIn": { + "@id": "nsg:isRegisteredIn" }, - "status": { - "@id": "nsg:status" + "algorithm": { + "@id": "schema:algorithm" }, - "widthResolution": { - "@id": "nsg:widthResolution" + "repetitions": { + "@id": "schema:repetitions" }, - "qualifiedUsage": { - "@id": "prov:qualifiedUsage" + "propertyID": { + "@id": "schema:propertyID" }, - "reagentVendor": { - "@id": "nsg:reagentVendor" + "startMembranePotential": { + "@id": "nsg:startMembranePotential" }, - "putativeEtype": { - "@id": "nsg:putativeEtype" + "hadActivity": { + "@id": "prov:hadActivity" }, - "topConceptOf": { - "@id": "skos:topConceptOf" + "subCellularModel": { + "@id": "nsg:subCellularModel" }, - "description": { - "@id": "schema:description" + "spatialIndex": { + "@id": "nsg:spatialIndex" }, - "type": { - "@id": "rdf:type" + "location": { + "@id": "nsg:location" }, - "channel": { - "@id": "nsg:channel" + "conformsTo": { + "@id": "nsg:conformsTo" }, - "providerExperimentId": { - "@id": "nsg:providerExperimentId" + "bestScore": { + "@id": "nsg:bestScore" }, - "edgePopulation": { - "@id": "nsg:edgePopulation" + "timeStep": { + "@id": "nsg:timeStep" }, - "coordinatesInBrainAtlas": { - "@id": "nsg:coordinatesInBrainAtlas" + "putativeMType": { + "@id": "nsg:putativeMType" }, - "heightResolution": { - "@id": "nsg:heightResolution" + "providerExperimentId": { + "@id": "nsg:providerExperimentId" }, - "quality": { - "@id": "nsg:quality" + "seriesResistance": { + "@id": "nsg:seriesResistance" }, - "label": { - "@id": "rdfs:label" + "atlasSpatialReferenceSystem": { + "@id": "nsg:atlasSpatialReferenceSystem" }, - "steps": { - "@id": "nsg:steps" + "license": { + "@id": "schema:license" }, - "hasBasalDendrite": { - "@id": "nsg:hasBasalDendrite" + "hasSelector": { + "@id": "nsg:hasSelector" }, - "view2d": { - "@id": "nsg:view2d" + "wasStartedBy": { + "@id": "prov:wasStartedBy" }, - "objectiveMagnification": { - "@id": "nsg:objectiveMagnification" + "valueX": { + "@id": "nsg:valueX" }, - "reconstructionRequested": { - "@id": "nsg:reconstructionRequested" + "heightResolution": { + "@id": "nsg:heightResolution" }, - "annotationAngle": { - "@id": "nsg:annotationAngle" + "row": { + "@id": "nsg:row" }, - "imageDirection": { - "@id": "nsg:imageDirection" + "widthResolution": { + "@id": "nsg:widthResolution" }, - "lowerPoint": { - "@id": "nsg:lowerPoint" + "spatialCellName": { + "@id": "nsg:spatialCellName" }, - "annotatorComment": { - "@id": "nsg:annotatorComment" + "subject": { + "@id": "nsg:subject" }, - "spatialReferenceSystem": { - "@id": "nsg:spatialReferenceSystem" + "edgePopulation": { + "@id": "nsg:edgePopulation" }, - "eType": { - "@id": "nsg:eType" + "materials": { + "@id": "nsg:materials" }, - "image": { - "@id": "schema:image" + "somaReconstructionType": { + "@id": "nsg:somaReconstructionType" }, - "temperature": { - "@id": "nsg:temperature" + "projectName": { + "@id": "nsg:projectName" }, - "invalidation": { - "@id": "nsg:invalidation" + "addressLocality": { + "@id": "schema:addressLocality" }, - "properties": { - "@id": "nsg:properties" + "morphologyRelease": { + "@id": "nsg:morphologyRelease" }, - "slicingPlane": { - "@id": "nsg:slicingPlane" + "parentOrganization": { + "@id": "schema:parentOrganization" }, - "startedAtTime": { - "@id": "prov:startedAtTime" + "hasSoma": { + "@id": "nsg:hasSoma" }, - "hasBody": { - "@id": "nsg:hasBody" + "eModel": { + "@id": "nsg:eModel" }, - "stimulus": { - "@id": "nsg:stimulus" + "age": { + "@id": "nsg:age" }, - "weight": { - "@id": "schema:weight" + "cellLibraryFile": { + "@id": "nsg:cellLibraryFile" }, - "numberOfSlices": { - "@id": "nsg:numberOfSlices" + "distanceToBoundary": { + "@id": "nsg:distanceToBoundary" }, - "reagentName": { - "@id": "nsg:reagentName" + "annotation": { + "@id": "nsg:annotation" }, - "column": { - "@id": "nsg:column" + "emodelRelease": { + "@id": "nsg:emodelRelease" }, - "experimentalCell": { - "@id": "nsg:experimentalCell" + "annotatorComment": { + "@id": "nsg:annotatorComment" }, - "morphologyIndex": { - "@id": "nsg:morphologyIndex" + "stain": { + "@id": "nsg:stain" }, - "streetAddress": { - "@id": "schema:streetAddress" + "sealResistance": { + "@id": "nsg:sealResistance" }, - "parcellationOntology": { - "@id": "nsg:parcellationOntology" + "imageVolume": { + "@id": "nsg:imageVolume" }, - "pipetteNumber": { - "@id": "nsg:pipetteNumber" + "imageModality": { + "@id": "nsg:imageModality" }, - "voxelType": { - "@id": "nsg:voxelType" + "coordinatesInSlice": { + "@id": "nsg:coordinatesInSlice" }, "birthDate": { "@id": "schema:birthDate" }, - "projectName": { - "@id": "nsg:projectName" - }, - "timeStep": { - "@id": "nsg:timeStep" + "transgenic": { + "@id": "nsg:transgenic" }, "stimuliToExperimentMap": { "@id": "nsg:stimuliToExperimentMap" }, - "qualifiedAssociation": { - "@id": "prov:qualifiedAssociation" + "secondRow": { + "@id": "nsg:secondRow" }, - "derivation": { - "@id": "nsg:derivation" + "author": { + "@id": "schema:author" }, - "inputResistance": { - "@id": "nsg:inputResistance" + "morphology": { + "@id": "nsg:morphology" }, - "familyName": { - "@id": "schema:familyName" + "normalizedScore": { + "@id": "nsg:normalizedScore" }, - "labelingCompound": { - "@id": "nsg:labelingCompound" + "memodelRelease": { + "@id": "nsg:memodelRelease" }, - "contribution": { - "@id": "nsg:contribution" + "email": { + "@id": "schema:email" }, - "reagentMolarWeight": { - "@id": "nsg:reagentMolarWeight" + "hemisphere": { + "@id": "nsg:hemisphere" }, - "solution": { - "@id": "nsg:solution" + "cuttingThickness": { + "@id": "nsg:cuttingThickness" }, - "positionInLayer": { - "@id": "nsg:positionInLayer" + "properties": { + "@id": "nsg:properties" }, - "electrodeResistance": { - "@id": "nsg:electrodeResistance" + "sliceHeight": { + "@id": "nsg:sliceHeight" }, - "templateVolume": { - "@id": "nsg:templateVolume" + "hypampThreshold": { + "@id": "nsg:hypampThreshold" }, - "prefLabel": { - "@id": "skos:prefLabel" + "topConceptOf": { + "@id": "skos:topConceptOf" }, - "edgeCollection": { - "@id": "nsg:edgeCollection" + "features": { + "@id": "nsg:features" }, - "sweep": { - "@id": "nsg:sweep" + "sliceIntervalValue": { + "@id": "nsg:sliceIntervalValue" }, - "digitalToAnalogConverter": { - "@id": "nsg:digitalToAnalogConverter" + "layer": { + "@id": "nsg:layer" }, - "features": { - "@id": "nsg:features" + "familyName": { + "@id": "schema:familyName" }, - "targetHoldingPotential": { - "@id": "nsg:targetHoldingPotential" + "wasDerivedFrom": { + "@id": "prov:wasDerivedFrom" }, - "gain": { - "@id": "nsg:gain" + "weight": { + "@id": "schema:weight" }, - "cellLine": { - "@id": "nsg:cellLine" + "hasSource": { + "@id": "nsg:hasSource" }, - "version": { - "@id": "schema:version" + "column": { + "@id": "nsg:column" }, - "hemisphere": { - "@id": "nsg:hemisphere" + "reagentName": { + "@id": "nsg:reagentName" }, - "reagentLinearFormula": { - "@id": "nsg:reagentLinearFormula" + "distance": { + "@id": "schema:distance" }, - "locationInSlice": { - "@id": "nsg:locationInSlice" + "citation": { + "@id": "schema:citation" }, - "subject": { - "@id": "nsg:subject" + "treatment": { + "@id": "nsg:treatment" }, - "subCellularMechanism": { - "@id": "nsg:subCellularMechanism" + "generation": { + "@id": "nsg:generation" }, - "providerExperimentName": { - "@id": "nsg:providerExperimentName" + "faxNumber": { + "@id": "schema:faxNumber" }, - "sliceIntervalValue": { - "@id": "nsg:sliceIntervalValue" + "definition": { + "@id": "skos:definition" }, - "fixationMethod": { - "@id": "nsg:fixationMethod" + "type": { + "@id": "rdf:type" }, - "axonProjection": { - "@id": "nsg:axonProjection" + "objectiveMagnification": { + "@id": "nsg:objectiveMagnification" }, - "sliceHeight": { - "@id": "nsg:sliceHeight" + "chlorideReversalPotential": { + "@id": "nsg:chlorideReversalPotential" }, - "addressCountry": { - "@id": "schema:addressCountry" + "contentUrl": { + "@id": "schema:contentUrl" + }, + "digest": { + "@id": "nsg:digest" }, - "objectiveType": { - "@id": "nsg:objectiveType" + "positionInLayer": { + "@id": "nsg:positionInLayer" }, - "algorithm": { - "@id": "schema:algorithm" + "compensationCurrent": { + "@id": "nsg:compensationCurrent" }, - "startMembranePotential": { - "@id": "nsg:startMembranePotential" + "eCode": { + "@id": "nsg:eCode" }, - "modelOf": { - "@id": "nsg:modelOf" + "mainModelScript": { + "@id": "nsg:mainModelScript" }, - "telephone": { - "@id": "schema:telephone" + "mountingMedia": { + "@id": "nsg:mountingMedia" + }, + "hasBody": { + "@id": "nsg:hasBody" }, "hadPlan": { "@id": "prov:hadPlan" }, - "parentOrganization": { - "@id": "schema:parentOrganization" - }, - "dateModified": { - "@id": "schema:dateModified" + "parcellationOntology": { + "@id": "nsg:parcellationOntology" }, - "coordinatesInSlice": { - "@id": "nsg:coordinatesInSlice" + "inputResistance": { + "@id": "nsg:inputResistance" }, - "eCode": { - "@id": "nsg:eCode" + "derivation": { + "@id": "nsg:derivation" }, - "annotation": { - "@id": "nsg:annotation" + "pipetteResistance": { + "@id": "nsg:pipetteResistance" }, - "measuredHoldingPotential": { - "@id": "nsg:measuredHoldingPotential" + "reagentLinearFormula": { + "@id": "nsg:reagentLinearFormula" }, - "imports": { - "@id": "owl:imports" + "language": { + "@id": "schema:language" }, - "cuttingThickness": { - "@id": "nsg:cuttingThickness" + "reagentVendor": { + "@id": "nsg:reagentVendor" }, - "vendor": { - "@id": "nsg:vendor" + "compressionCorrection": { + "@id": "nsg:compressionCorrection" }, - "sameAs": { - "@id": "schema:sameAs" + "source": { + "@id": "nsg:source" }, - "electrodeNumber": { - "@id": "nsg:electrodeNumber" + "providerExperimentName": { + "@id": "nsg:providerExperimentName" }, - "maxValue": { - "@id": "schema:maxValue" + "agent": { + "@id": "prov:agent" }, - "longitudinalAxis": { - "@id": "nsg:longitudinalAxis" + "contribution": { + "@id": "nsg:contribution" }, - "dateCreated": { - "@id": "schema:dateCreated" + "pipetteNumber": { + "@id": "nsg:pipetteNumber" }, - "hadActivity": { - "@id": "prov:hadActivity" + "memodelIndex": { + "@id": "nsg:memodelIndex" }, - "definition": { - "@id": "skos:definition" + "emodelIndex": { + "@id": "nsg:emodelIndex" }, - "normalizedScore": { - "@id": "nsg:normalizedScore" + "period": { + "@id": "nsg:period" }, - "emodelRelease": { - "@id": "nsg:emodelRelease" + "voxelType": { + "@id": "nsg:voxelType" }, - "thirdRow": { - "@id": "nsg:thirdRow" + "additionalName": { + "@id": "schema:additionalName" }, - "spatialCellName": { - "@id": "nsg:spatialCellName" + "objectiveType": { + "@id": "nsg:objectiveType" }, - "email": { - "@id": "schema:email" + "parcellationVolume": { + "@id": "nsg:parcellationVolume" }, - "radius": { - "@id": "nsg:radius" + "axonProjection": { + "@id": "nsg:axonProjection" }, - "hasSoma": { - "@id": "nsg:hasSoma" + "orientation": { + "@id": "nsg:orientation" }, "contentSize": { "@id": "schema:contentSize" }, - "minValue": { - "@id": "schema:minValue" - }, - "hasApicalDendrite": { - "@id": "nsg:hasApicalDendrite" - }, - "stain": { - "@id": "nsg:stain" + "modelOf": { + "@id": "nsg:modelOf" }, - "slicingAngle": { - "@id": "nsg:slicingAngle" + "boundingBox": { + "@id": "nsg:boundingBox" }, - "row": { - "@id": "nsg:row" + "scale": { + "@id": "nsg:scale" }, - "transgenic": { - "@id": "nsg:transgenic" + "strain": { + "@id": "nsg:strain" }, - "compensationCurrent": { - "@id": "nsg:compensationCurrent" + "datePublished": { + "@id": "schema:datePublished" }, - "morphologyRelease": { - "@id": "nsg:morphologyRelease" + "reconstructionRequested": { + "@id": "nsg:reconstructionRequested" }, - "sealResistance": { - "@id": "nsg:sealResistance" + "invalidation": { + "@id": "nsg:invalidation" }, - "upperPoint": { - "@id": "nsg:upperPoint" + "wasAssociatedWith": { + "@id": "prov:wasAssociatedWith" }, - "subCellularModel": { - "@id": "nsg:subCellularModel" + "score": { + "@id": "nsg:score" }, "reconstructable": { "@id": "nsg:reconstructable" }, - "mountingMedia": { - "@id": "nsg:mountingMedia" - }, - "dateOfSurgery": { - "@id": "nsg:dateOfSurgery" + "givenName": { + "@id": "schema:givenName" }, - "emodelIndex": { - "@id": "nsg:emodelIndex" + "electrodeNumber": { + "@id": "nsg:electrodeNumber" }, - "featureExtractionConfiguration": { - "@id": "nsg:featureExtractionConfiguration" + "coordinatesInBrainAtlas": { + "@id": "nsg:coordinatesInBrainAtlas" }, - "somaReconstructionType": { - "@id": "nsg:somaReconstructionType" + "bathSolution": { + "@id": "nsg:bathSolution" }, "address": { "@id": "schema:address" }, - "size": { - "@id": "schema:size" + "url": { + "@id": "schema:url" }, - "layer": { - "@id": "nsg:layer" + "valueZ": { + "@id": "nsg:valueZ" }, - "distanceToBoundary": { - "@id": "nsg:distanceToBoundary" + "lowerPoint": { + "@id": "nsg:lowerPoint" }, - "additionalName": { - "@id": "schema:additionalName" + "endedAtTime": { + "@id": "prov:endedAtTime" }, - "imageVolume": { - "@id": "nsg:imageVolume" + "edgeCollection": { + "@id": "nsg:edgeCollection" }, - "variable": { - "@id": "nsg:variable" + "affiliation": { + "@id": "schema:affiliation" }, - "liquidJunctionPotential": { - "@id": "nsg:liquidJunctionPotential" + "telephone": { + "@id": "schema:telephone" }, - "hasAxon": { - "@id": "nsg:hasAxon" + "longitudinalAxis": { + "@id": "nsg:longitudinalAxis" }, - "postalCode": { - "@id": "schema:postalCode" + "disease": { + "@id": "nsg:disease" }, - "wasAssociatedWith": { - "@id": "prov:wasAssociatedWith" + "index": { + "@id": "nsg:index" }, - "compressionCorrection": { - "@id": "nsg:compressionCorrection" + "wasGeneratedBy": { + "@id": "prov:wasGeneratedBy" }, - "sex": { - "@id": "nsg:sex" + "analogToDigitalConverter": { + "@id": "nsg:analogToDigitalConverter" }, - "sliceResolution": { - "@id": "nsg:sliceResolution" + "diseaseModel": { + "@id": "nsg:diseaseModel" }, - "sliceInterval": { - "@id": "nsg:sliceInterval" + "sliceWidth": { + "@id": "nsg:sliceWidth" }, - "wasStartedBy": { - "@id": "prov:wasStartedBy" + "firstRow": { + "@id": "nsg:firstRow" }, - "origin": { - "@id": "nsg:origin" + "dateCreated": { + "@id": "schema:dateCreated" }, - "repetition": { - "@id": "nsg:repetition" + "hadUsage": { + "@id": "prov:hadUsage" }, - "imageOrigin": { - "@id": "nsg:imageOrigin" + "hasApicalDendrite": { + "@id": "nsg:hasApicalDendrite" + }, + "sameAs": { + "@id": "schema:sameAs" + }, + "postalCode": { + "@id": "schema:postalCode" + }, + "view2d": { + "@id": "nsg:view2d" }, - "nsg": "https://neuroshapes.org/" + "dc": "http://purl.org/dc/elements/1.1/", + "dcat": "http://www.w3.org/ns/dcat#", + "dcterms": "http://purl.org/dc/terms/", + "nsg": "https://neuroshapes.org/", + "nxv": "https://bluebrain.github.io/nexus/vocabulary/", + "owl": "http://www.w3.org/2002/07/owl#", + "prov": "http://www.w3.org/ns/prov#", + "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#", + "rdfs": "http://www.w3.org/2000/01/rdf-schema#", + "schema": "http://schema.org/", + "sh": "http://www.w3.org/ns/shacl#", + "shsh": "http://www.w3.org/ns/shacl-shacl#", + "skos": "http://www.w3.org/2004/02/skos/core#", + "vann": "http://purl.org/vocab/vann/", + "void": "http://rdfs.org/ns/void#", + "xml": "http://www.w3.org/XML/1998/namespace", + "xsd": "http://www.w3.org/2001/XMLSchema#" } } diff --git a/docs/.DS_Store b/docs/.DS_Store new file mode 100644 index 00000000..24c05ca8 Binary files /dev/null and b/docs/.DS_Store differ diff --git a/docs/contact.html b/docs/contact.html index f20c090b..a3ae60b5 100644 --- a/docs/contact.html +++ b/docs/contact.html @@ -178,7 +178,7 @@ @@ -198,7 +198,7 @@

<
-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/data-models/brainatlas/brain-atlas-derivation.html b/docs/data-models/brainatlas/brain-atlas-derivation.html index c2ba4d5e..5617dc6b 100644 --- a/docs/data-models/brainatlas/brain-atlas-derivation.html +++ b/docs/data-models/brainatlas/brain-atlas-derivation.html @@ -158,7 +158,7 @@
@@ -254,7 +254,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/data-models/brainatlas/brain-atlas.html b/docs/data-models/brainatlas/brain-atlas.html index d59de16c..d55d303c 100644 --- a/docs/data-models/brainatlas/brain-atlas.html +++ b/docs/data-models/brainatlas/brain-atlas.html @@ -185,7 +185,7 @@
@@ -227,7 +227,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/brainatlas/registering-brain-atlas.html b/docs/data-models/brainatlas/registering-brain-atlas.html index 74ad7ddc..c2f8af32 100644 --- a/docs/data-models/brainatlas/registering-brain-atlas.html +++ b/docs/data-models/brainatlas/registering-brain-atlas.html @@ -197,7 +197,7 @@
@@ -261,43 +261,43 @@

- SubjectCollection + SubjectCollection A collection of subject to be used in the experiment - TemplateImageData + TemplateImageData Template image data acquired and processed from the subject collection - ParcellationImageData + ParcellationImageData Parcellation image data generated from the template image data - ParcellationLabel + ParcellationLabel Parcellation labels correspond to the annotations in the parcellation image - TemplateVolume + TemplateVolume Template volume generated from the template image data - ParcellationVolume + ParcellationVolume Parcellation volume generated from the parcellation image data - ParcellationOntology + ParcellationOntology Parcellation ontology converted from the parcellation label - AtlasSpatialReferenceSystem + AtlasSpatialReferenceSystem The spatial coordinate system of the atlas space - AtlasRelease + AtlasRelease An atlas release comprises template volume, parcellation volume, parcellation ontology as well as the atlas spatial reference system - Protocol + Protocol Protocol that describes the method used in the design and execution of the experiment @@ -312,19 +312,19 @@

Atlas Construction + Atlas Construction Process to construct a brain atlas - Template Reconstruction + Template Reconstruction Reconstruct the template image data into volumetric representation - Parcellation Reconstruction + Parcellation Reconstruction Reconstruct the parcellation image data into volumetric representation - Ontology Conversion + Ontology Conversion Convert the parcellation label into ontological representation @@ -339,15 +339,15 @@

- Person + Person Person associated with an activity - SoftwareAgent + SoftwareAgent Software associated with an activity - Organization + Organization Organization associated with an activity @@ -369,7 +369,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/brainatlas/registering-whole-brain-morphology.html b/docs/data-models/brainatlas/registering-whole-brain-morphology.html index 6a970206..4ec1cf4a 100644 --- a/docs/data-models/brainatlas/registering-whole-brain-morphology.html +++ b/docs/data-models/brainatlas/registering-whole-brain-morphology.html @@ -197,7 +197,7 @@
@@ -258,31 +258,31 @@

- Subject + Subject Subject that was used in the experiment - TemplateVolume + TemplateVolume Template volume generated from the template image data - AtlasSpatialReferenceSystem + AtlasSpatialReferenceSystem The spatial coordinate system of the atlas space - ImageStack + ImageStack Image stack obtained from the brain tissue of the subject - ReconstructedCell + ReconstructedCell Reconstructed cell - Transform + Transform A linear or non-linear transform - Protocol + Protocol Protocol that describes the method used in the design and execution of the experiment @@ -297,15 +297,15 @@

BrainImaging + BrainImaging Technique used to obtain an image stack of the brain tissue containing the cells for reconstruction - ReconstructionFromImage + ReconstructionFromImage Technique used to reconstruct the stained cell - Transformation + Transformation Transform a geometric object @@ -320,15 +320,15 @@

- Person + Person Person associated with an activity - SoftwareAgent + SoftwareAgent Software associated with an activity - Organization + Organization Organization associated with an activity @@ -350,7 +350,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/electrophysiology/electrophysiology.html b/docs/data-models/electrophysiology/electrophysiology.html index f96221c1..f01d0686 100644 --- a/docs/data-models/electrophysiology/electrophysiology.html +++ b/docs/data-models/electrophysiology/electrophysiology.html @@ -185,7 +185,7 @@
@@ -226,7 +226,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html b/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html index 9153964a..8df1a7c5 100644 --- a/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html +++ b/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html @@ -197,7 +197,7 @@
@@ -260,31 +260,31 @@

- Subject + Subject Subject that was used in the experiment - Slice + Slice Brain slice obtained from the subject - IntraCellularSharpElectrodeRecordedSlice + IntraCellularSharpElectrodeRecordedSlice Brain slice containing recorded cells - IntraSharpRecordedCellCollection + IntraSharpRecordedCellCollection Collection of recorded cells in a single slice - IntraCellularSharpElectrodeRecordedCell + IntraCellularSharpElectrodeRecordedCell Cell that was recorded in the slice - Trace + Trace Individual recording trace of the cell (stimulation/input and response/output trace) - Protocol + Protocol Protocol that describes the method used in the design and execution of the experiment @@ -300,15 +300,15 @@

BrainSlicing + BrainSlicing Technique used to obtain a brain slice - IntraCellularSharpElectrode + IntraCellularSharpElectrode Technique used to study electrical activity of individual living cells - StimulusExperiment + StimulusExperiment Technique used to obtain the electrical signature of cells through injection of a defined current pattern @@ -324,15 +324,15 @@

- Person + Person Person associated with an activity - SoftwareAgent + SoftwareAgent Software associated with an activity - Organization + Organization Organization associated with an activity @@ -355,7 +355,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html b/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html index 7e43a6db..c1e629f3 100644 --- a/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html +++ b/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html @@ -197,7 +197,7 @@
@@ -261,31 +261,31 @@

- Subject + Subject Subject that was used in the experiment - Slice + Slice Brain slice obtained from the subject - PatchedSlice + PatchedSlice Brain slice containing patched cells - PatchedCellCollection + PatchedCellCollection Collection of patched cells in a single slice (e.g. for multi-patch recordings) - PatchedCell + PatchedCell Cell that was patched in the slice - Trace + Trace Individual recording trace of the patched cell (stimulation/input and response/output trace) - Protocol + Protocol Protocol that describes the method used in the design and execution of the experiment @@ -301,15 +301,15 @@

BrainSlicing + BrainSlicing Technique used to obtain a brain slice for patching - WholeCellPatchClamp + WholeCellPatchClamp Technique used to study electrical activity of individual living cells - StimulusExperiment + StimulusExperiment Technique used to obtain the electrical signature of cells through injection of a defined current pattern @@ -325,15 +325,15 @@

- Person + Person Person associated with an activity - SoftwareAgent + SoftwareAgent Software associated with an activity - Organization + Organization Organization associated with an activity @@ -356,7 +356,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/index.html b/docs/data-models/index.html index 24c788bb..62f54d81 100644 --- a/docs/data-models/index.html +++ b/docs/data-models/index.html @@ -185,7 +185,7 @@
@@ -227,7 +227,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/data-models/literature/annotation.html b/docs/data-models/literature/annotation.html index 961e6015..43180b8d 100644 --- a/docs/data-models/literature/annotation.html +++ b/docs/data-models/literature/annotation.html @@ -159,7 +159,7 @@
@@ -196,7 +196,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/literature/literature.html b/docs/data-models/literature/literature.html index 76300339..35e9333d 100644 --- a/docs/data-models/literature/literature.html +++ b/docs/data-models/literature/literature.html @@ -154,7 +154,7 @@
@@ -191,7 +191,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/literature/literatureannotation.html b/docs/data-models/literature/literatureannotation.html index a4b9ff96..f09f0f2d 100644 --- a/docs/data-models/literature/literatureannotation.html +++ b/docs/data-models/literature/literatureannotation.html @@ -164,7 +164,7 @@
@@ -228,7 +228,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/data-models/literature/neuronclassification.html b/docs/data-models/literature/neuronclassification.html index 20efe43a..df97bb23 100644 --- a/docs/data-models/literature/neuronclassification.html +++ b/docs/data-models/literature/neuronclassification.html @@ -155,7 +155,7 @@
@@ -201,7 +201,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/data-models/literature/parameter.html b/docs/data-models/literature/parameter.html index b5d9b0e0..57bcd9a5 100644 --- a/docs/data-models/literature/parameter.html +++ b/docs/data-models/literature/parameter.html @@ -159,7 +159,7 @@
@@ -196,7 +196,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/literature/provenance.html b/docs/data-models/literature/provenance.html index 4231da2f..4880b3d1 100644 --- a/docs/data-models/literature/provenance.html +++ b/docs/data-models/literature/provenance.html @@ -159,7 +159,7 @@
@@ -196,7 +196,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/minds/minds.html b/docs/data-models/minds/minds.html index 14b7acc2..6008dd9d 100644 --- a/docs/data-models/minds/minds.html +++ b/docs/data-models/minds/minds.html @@ -154,7 +154,7 @@
@@ -203,7 +203,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/minds/model.html b/docs/data-models/minds/model.html index 03e91b44..290986ff 100644 --- a/docs/data-models/minds/model.html +++ b/docs/data-models/minds/model.html @@ -143,7 +143,7 @@
@@ -163,7 +163,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/data-models/minds/namespace.html b/docs/data-models/minds/namespace.html index 20c43b26..b96c3df9 100644 --- a/docs/data-models/minds/namespace.html +++ b/docs/data-models/minds/namespace.html @@ -143,7 +143,7 @@
@@ -163,7 +163,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/minds/ontology.html b/docs/data-models/minds/ontology.html index 8b4bde71..81c38ad7 100644 --- a/docs/data-models/minds/ontology.html +++ b/docs/data-models/minds/ontology.html @@ -143,7 +143,7 @@
@@ -163,7 +163,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/data-models/minds/schemas.html b/docs/data-models/minds/schemas.html index fbb7bed1..be8c290e 100644 --- a/docs/data-models/minds/schemas.html +++ b/docs/data-models/minds/schemas.html @@ -143,7 +143,7 @@
@@ -163,7 +163,7 @@

<
-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/data-models/minds/taxonomy.html b/docs/data-models/minds/taxonomy.html index 9cf2e7de..813200ef 100644 --- a/docs/data-models/minds/taxonomy.html +++ b/docs/data-models/minds/taxonomy.html @@ -143,7 +143,7 @@
@@ -163,7 +163,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/data-models/minds/vocabulary.html b/docs/data-models/minds/vocabulary.html index a4a8d336..aec59dc3 100644 --- a/docs/data-models/minds/vocabulary.html +++ b/docs/data-models/minds/vocabulary.html @@ -150,7 +150,7 @@
@@ -187,7 +187,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/morphology/morphology-reconstruction.html b/docs/data-models/morphology/morphology-reconstruction.html index e036ec31..2a584952 100644 --- a/docs/data-models/morphology/morphology-reconstruction.html +++ b/docs/data-models/morphology/morphology-reconstruction.html @@ -197,7 +197,7 @@
@@ -262,47 +262,47 @@

- Subject + Subject Subject that was used in the experiment - Slice + Slice Brain slice obtained from the subject - PatchedSlice + PatchedSlice Brain slice containing patched cells - PatchedCellCollection + PatchedCellCollection Collection of patched cells in a single slice (e.g. for multi-patch recordings) - PatchedCell + PatchedCell Cell that was patched in the slice - FixedStainedSlice + FixedStainedSlice Brain slice after fixation and staining - AnnotatedSlice + AnnotatedSlice Brain slice containing the identified and annotated stained cells - LabeledCellCollection + LabeledCellCollection Collection of labeled cells in a single slice - LabeledCell + LabeledCell Cell that was labeled in the slice - ReconstructedCell + ReconstructedCell Reconstructed cell - Protocol + Protocol Protocol that describes the method used in the design and execution of the experiment @@ -318,23 +318,23 @@

BrainSlicing + BrainSlicing Technique used to obtain a brain slice for patching - WholeCellPatchClamp + WholeCellPatchClamp Technique used to study electrical activity of individual living cells - FixationStainingMounting + FixationStainingMounting Technique used to fix and stain the slice - AcquisitionAnnotation + AcquisitionAnnotation Technique used to acquire an image of the slice and annotate the stained cells - Reconstruction + Reconstruction Technique used to reconstruct the stained cell @@ -350,15 +350,15 @@

- Person + Person Person associated with an activity - SoftwareAgent + SoftwareAgent Software associated with an activity - Organization + Organization Organization associated with an activity @@ -381,7 +381,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/morphology/morphology.html b/docs/data-models/morphology/morphology.html index fb33a24b..bb72a664 100644 --- a/docs/data-models/morphology/morphology.html +++ b/docs/data-models/morphology/morphology.html @@ -178,7 +178,7 @@
@@ -202,7 +202,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html b/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html index ab76ea23..884e83d8 100644 --- a/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html +++ b/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html @@ -197,7 +197,7 @@
@@ -262,19 +262,19 @@

- Subject + Subject Subject that was used in the experiment - ImageStack + ImageStack Image stack obtained from the brain tissue of the subject - ReconstructedCell + ReconstructedCell Reconstructed cell - Protocol + Protocol Protocol that describes the method used in the design and execution of the experiment @@ -290,11 +290,11 @@

BrainImaging + BrainImaging Technique used to obtain an image stack of the brain tissue containing the cells for reconstruction - ReconstructionFromImage + ReconstructionFromImage Technique used to reconstruct the stained cell @@ -310,15 +310,15 @@

- Person + Person Person associated with an activity - SoftwareAgent + SoftwareAgent Software associated with an activity - Organization + Organization Organization associated with an activity @@ -341,7 +341,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/neuronclassification/annotation.html b/docs/data-models/neuronclassification/annotation.html index de9a9f94..d41c4986 100644 --- a/docs/data-models/neuronclassification/annotation.html +++ b/docs/data-models/neuronclassification/annotation.html @@ -152,7 +152,7 @@
@@ -172,7 +172,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/neuronclassification/literature.html b/docs/data-models/neuronclassification/literature.html index 80fc2e26..5b6af67e 100644 --- a/docs/data-models/neuronclassification/literature.html +++ b/docs/data-models/neuronclassification/literature.html @@ -154,7 +154,7 @@
@@ -191,7 +191,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/neuronclassification/literatureannotation.html b/docs/data-models/neuronclassification/literatureannotation.html index a8291f19..74ddecbf 100644 --- a/docs/data-models/neuronclassification/literatureannotation.html +++ b/docs/data-models/neuronclassification/literatureannotation.html @@ -164,7 +164,7 @@
@@ -228,7 +228,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/data-models/neuronclassification/neuronclassification.html b/docs/data-models/neuronclassification/neuronclassification.html index d9e2a815..ce1ced73 100644 --- a/docs/data-models/neuronclassification/neuronclassification.html +++ b/docs/data-models/neuronclassification/neuronclassification.html @@ -155,7 +155,7 @@
@@ -201,7 +201,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/data-models/neuronclassification/parameter.html b/docs/data-models/neuronclassification/parameter.html index c3173121..990f797d 100644 --- a/docs/data-models/neuronclassification/parameter.html +++ b/docs/data-models/neuronclassification/parameter.html @@ -159,7 +159,7 @@
@@ -196,7 +196,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/neuronclassification/provenance.html b/docs/data-models/neuronclassification/provenance.html index 246c1d76..45f611ec 100644 --- a/docs/data-models/neuronclassification/provenance.html +++ b/docs/data-models/neuronclassification/provenance.html @@ -159,7 +159,7 @@
@@ -196,7 +196,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/data-models/ngv/molecule.html b/docs/data-models/ngv/molecule.html index 36240fcb..129e2e98 100644 --- a/docs/data-models/ngv/molecule.html +++ b/docs/data-models/ngv/molecule.html @@ -157,7 +157,7 @@
@@ -259,7 +259,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/data-models/ngv/new.html b/docs/data-models/ngv/new.html index 92c43c74..24b01c59 100644 --- a/docs/data-models/ngv/new.html +++ b/docs/data-models/ngv/new.html @@ -157,7 +157,7 @@
@@ -259,7 +259,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/datamodeling/index.html b/docs/datamodeling/index.html index 3ff9277f..91916e9a 100644 --- a/docs/datamodeling/index.html +++ b/docs/datamodeling/index.html @@ -178,7 +178,7 @@
@@ -198,7 +198,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/datamodeling/linkeddata/index.html b/docs/datamodeling/linkeddata/index.html index 9f387d0e..6e5ba74c 100644 --- a/docs/datamodeling/linkeddata/index.html +++ b/docs/datamodeling/linkeddata/index.html @@ -143,7 +143,7 @@
@@ -163,7 +163,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/datamodeling/linkeddata/rdf/index.html b/docs/datamodeling/linkeddata/rdf/index.html index 1c1fef9d..43aa9b1b 100644 --- a/docs/datamodeling/linkeddata/rdf/index.html +++ b/docs/datamodeling/linkeddata/rdf/index.html @@ -170,7 +170,7 @@
@@ -265,7 +265,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/datamodeling/linkeddata/rdf/json-ld.html b/docs/datamodeling/linkeddata/rdf/json-ld.html index d190e254..3324011e 100644 --- a/docs/datamodeling/linkeddata/rdf/json-ld.html +++ b/docs/datamodeling/linkeddata/rdf/json-ld.html @@ -160,7 +160,7 @@
@@ -180,7 +180,7 @@

<
-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/datamodeling/linkeddata/rdf/readings.html b/docs/datamodeling/linkeddata/rdf/readings.html index e5fd9bed..cce38d4d 100644 --- a/docs/datamodeling/linkeddata/rdf/readings.html +++ b/docs/datamodeling/linkeddata/rdf/readings.html @@ -160,7 +160,7 @@
@@ -179,7 +179,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/datamodeling/linkeddata/rdf/uris.html b/docs/datamodeling/linkeddata/rdf/uris.html index 88b3b7af..e0d8f499 100644 --- a/docs/datamodeling/linkeddata/rdf/uris.html +++ b/docs/datamodeling/linkeddata/rdf/uris.html @@ -160,7 +160,7 @@
@@ -179,7 +179,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/datamodeling/why-validation.html b/docs/datamodeling/why-validation.html index 8735ad95..9b75627e 100644 --- a/docs/datamodeling/why-validation.html +++ b/docs/datamodeling/why-validation.html @@ -151,7 +151,7 @@
@@ -190,7 +190,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/gettingstarted/contribution.html b/docs/gettingstarted/contribution.html index 5a9209a2..7b9fcbd4 100644 --- a/docs/gettingstarted/contribution.html +++ b/docs/gettingstarted/contribution.html @@ -194,7 +194,7 @@
@@ -345,7 +345,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/gettingstarted/download.html b/docs/gettingstarted/download.html index 94c117f1..d13fcc82 100644 --- a/docs/gettingstarted/download.html +++ b/docs/gettingstarted/download.html @@ -178,7 +178,7 @@
@@ -230,7 +230,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/gettingstarted/index.html b/docs/gettingstarted/index.html index a9cf1c93..0f5e1562 100644 --- a/docs/gettingstarted/index.html +++ b/docs/gettingstarted/index.html @@ -178,7 +178,7 @@
@@ -197,7 +197,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/gettingstarted/overview.html b/docs/gettingstarted/overview.html index 1611103d..33d337c7 100644 --- a/docs/gettingstarted/overview.html +++ b/docs/gettingstarted/overview.html @@ -178,7 +178,7 @@
@@ -205,7 +205,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/index.html b/docs/index.html index cb3cf663..25127e0c 100644 --- a/docs/index.html +++ b/docs/index.html @@ -182,7 +182,7 @@
@@ -238,7 +238,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/license.html b/docs/license.html index a41c25f5..23465fdf 100644 --- a/docs/license.html +++ b/docs/license.html @@ -178,7 +178,7 @@
@@ -198,7 +198,7 @@

<
-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
diff --git a/docs/meetings.html b/docs/meetings.html index 682625dd..59e2936c 100644 --- a/docs/meetings.html +++ b/docs/meetings.html @@ -189,7 +189,7 @@
@@ -239,7 +239,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/publication/index.html b/docs/publication/index.html index 534dbeaa..e7ab97cd 100644 --- a/docs/publication/index.html +++ b/docs/publication/index.html @@ -143,7 +143,7 @@
@@ -162,7 +162,7 @@

-0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/releases.html b/docs/releases.html index 9440de5b..6411cfeb 100644 --- a/docs/releases.html +++ b/docs/releases.html @@ -190,7 +190,7 @@
@@ -285,7 +285,7 @@

https://provshapes.org/dash/activity schema
  • https://provshapes.org/dash/person
  • https://provshapes.org/dash/organization
    • -
  • https://neuroshapes.org/dash/entity schema
    • +
  • https://provshapes.org/dash/entity schema
  • https://provshapes.org/dash/collection
  • Reused usage shape in activity shape
    • @@ -319,7 +319,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/_convention.html b/docs/shacl-tutorial/_convention.html index 89c51197..7f7f4b7b 100644 --- a/docs/shacl-tutorial/_convention.html +++ b/docs/shacl-tutorial/_convention.html @@ -143,7 +143,7 @@
    @@ -163,7 +163,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
    diff --git a/docs/shacl-tutorial/further-readings/_index.html b/docs/shacl-tutorial/further-readings/_index.html index fe24af74..40964b6e 100644 --- a/docs/shacl-tutorial/further-readings/_index.html +++ b/docs/shacl-tutorial/further-readings/_index.html @@ -143,7 +143,7 @@
    @@ -163,7 +163,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
    diff --git a/docs/shacl-tutorial/further-readings/_what-is-shacl.html b/docs/shacl-tutorial/further-readings/_what-is-shacl.html index eef42a72..f8e4ef30 100644 --- a/docs/shacl-tutorial/further-readings/_what-is-shacl.html +++ b/docs/shacl-tutorial/further-readings/_what-is-shacl.html @@ -143,7 +143,7 @@
    @@ -163,7 +163,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/getting-started.html b/docs/shacl-tutorial/getting-started.html index bb8814e2..e7b569c9 100644 --- a/docs/shacl-tutorial/getting-started.html +++ b/docs/shacl-tutorial/getting-started.html @@ -173,7 +173,7 @@
    @@ -363,7 +363,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/how-to/_index.html b/docs/shacl-tutorial/how-to/_index.html index 0a3b396c..2ec37983 100644 --- a/docs/shacl-tutorial/how-to/_index.html +++ b/docs/shacl-tutorial/how-to/_index.html @@ -143,7 +143,7 @@
    @@ -162,7 +162,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
    diff --git a/docs/shacl-tutorial/how-to/_reuse-a-shacl-schemas.html b/docs/shacl-tutorial/how-to/_reuse-a-shacl-schemas.html index c532e481..a1273d6f 100644 --- a/docs/shacl-tutorial/how-to/_reuse-a-shacl-schemas.html +++ b/docs/shacl-tutorial/how-to/_reuse-a-shacl-schemas.html @@ -143,7 +143,7 @@
    @@ -162,7 +162,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
    diff --git a/docs/shacl-tutorial/how-to/_write-shacl-schemas.html b/docs/shacl-tutorial/how-to/_write-shacl-schemas.html index 345318c4..152b4772 100644 --- a/docs/shacl-tutorial/how-to/_write-shacl-schemas.html +++ b/docs/shacl-tutorial/how-to/_write-shacl-schemas.html @@ -143,7 +143,7 @@
    @@ -162,7 +162,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
    diff --git a/docs/shacl-tutorial/index-old.html b/docs/shacl-tutorial/index-old.html index 519a879f..e1882721 100644 --- a/docs/shacl-tutorial/index-old.html +++ b/docs/shacl-tutorial/index-old.html @@ -162,7 +162,7 @@
    @@ -211,7 +211,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
    diff --git a/docs/shacl-tutorial/index.html b/docs/shacl-tutorial/index.html index 3a317131..10577f93 100644 --- a/docs/shacl-tutorial/index.html +++ b/docs/shacl-tutorial/index.html @@ -143,7 +143,7 @@
    @@ -169,7 +169,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/namespaces.html b/docs/shacl-tutorial/namespaces.html index f82d6c56..9a3132bb 100644 --- a/docs/shacl-tutorial/namespaces.html +++ b/docs/shacl-tutorial/namespaces.html @@ -143,7 +143,7 @@
    @@ -163,7 +163,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/nexus-kg-schemas/_index.html b/docs/shacl-tutorial/nexus-kg-schemas/_index.html index 0d570855..2cbd4bdb 100644 --- a/docs/shacl-tutorial/nexus-kg-schemas/_index.html +++ b/docs/shacl-tutorial/nexus-kg-schemas/_index.html @@ -143,7 +143,7 @@
    @@ -162,7 +162,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
    diff --git a/docs/shacl-tutorial/nexus-kg-schemas/_nexus-shacl-schemas.html b/docs/shacl-tutorial/nexus-kg-schemas/_nexus-shacl-schemas.html index b329f703..c9ad1cf6 100644 --- a/docs/shacl-tutorial/nexus-kg-schemas/_nexus-shacl-schemas.html +++ b/docs/shacl-tutorial/nexus-kg-schemas/_nexus-shacl-schemas.html @@ -150,7 +150,7 @@
    @@ -408,7 +408,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/overview/_why-shacl.html b/docs/shacl-tutorial/overview/_why-shacl.html index cb7a2e53..4361c204 100644 --- a/docs/shacl-tutorial/overview/_why-shacl.html +++ b/docs/shacl-tutorial/overview/_why-shacl.html @@ -143,7 +143,7 @@
    @@ -162,7 +162,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/overview/constraints.html b/docs/shacl-tutorial/overview/constraints.html index 7a7edb23..05dd2583 100644 --- a/docs/shacl-tutorial/overview/constraints.html +++ b/docs/shacl-tutorial/overview/constraints.html @@ -156,7 +156,7 @@
    @@ -606,7 +606,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/overview/data-modeling-approach.html b/docs/shacl-tutorial/overview/data-modeling-approach.html index 03c355ba..7e9d5bf3 100644 --- a/docs/shacl-tutorial/overview/data-modeling-approach.html +++ b/docs/shacl-tutorial/overview/data-modeling-approach.html @@ -160,7 +160,7 @@
    @@ -182,7 +182,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/overview/index.html b/docs/shacl-tutorial/overview/index.html index 0be47615..60e9985d 100644 --- a/docs/shacl-tutorial/overview/index.html +++ b/docs/shacl-tutorial/overview/index.html @@ -178,7 +178,7 @@
    @@ -226,7 +226,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
    diff --git a/docs/shacl-tutorial/overview/overview.html b/docs/shacl-tutorial/overview/overview.html index 3b48660b..ca039c51 100644 --- a/docs/shacl-tutorial/overview/overview.html +++ b/docs/shacl-tutorial/overview/overview.html @@ -152,7 +152,7 @@
    @@ -192,7 +192,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
    diff --git a/docs/shacl-tutorial/overview/shape-best-practices.html b/docs/shacl-tutorial/overview/shape-best-practices.html index b6e03c74..6af139b4 100644 --- a/docs/shacl-tutorial/overview/shape-best-practices.html +++ b/docs/shacl-tutorial/overview/shape-best-practices.html @@ -163,7 +163,7 @@
    @@ -413,7 +413,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/overview/shape-target.html b/docs/shacl-tutorial/overview/shape-target.html index 9fc433e2..cf55b606 100644 --- a/docs/shacl-tutorial/overview/shape-target.html +++ b/docs/shacl-tutorial/overview/shape-target.html @@ -153,7 +153,7 @@
    @@ -258,7 +258,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/overview/validation-flow-old.html b/docs/shacl-tutorial/overview/validation-flow-old.html index 529ebdce..1b46b65d 100644 --- a/docs/shacl-tutorial/overview/validation-flow-old.html +++ b/docs/shacl-tutorial/overview/validation-flow-old.html @@ -152,7 +152,7 @@
    @@ -217,7 +217,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
    diff --git a/docs/shacl-tutorial/overview/validation-flow.html b/docs/shacl-tutorial/overview/validation-flow.html index 38c66db8..ddc7b501 100644 --- a/docs/shacl-tutorial/overview/validation-flow.html +++ b/docs/shacl-tutorial/overview/validation-flow.html @@ -151,7 +151,7 @@
    @@ -204,7 +204,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
    diff --git a/docs/shacl-tutorial/overview/what-is-shacl.html b/docs/shacl-tutorial/overview/what-is-shacl.html index 9aa5c342..069ac3fe 100644 --- a/docs/shacl-tutorial/overview/what-is-shacl.html +++ b/docs/shacl-tutorial/overview/what-is-shacl.html @@ -169,7 +169,7 @@
    @@ -712,7 +712,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/shacl-schemas-best-practices/_index.html b/docs/shacl-tutorial/shacl-schemas-best-practices/_index.html index 60cc0b92..90ff293c 100644 --- a/docs/shacl-tutorial/shacl-schemas-best-practices/_index.html +++ b/docs/shacl-tutorial/shacl-schemas-best-practices/_index.html @@ -143,7 +143,7 @@
    @@ -162,7 +162,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
    diff --git a/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html b/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html index de5dc0a0..52c6887a 100644 --- a/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html +++ b/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html @@ -162,7 +162,7 @@
    @@ -410,7 +410,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/shacl-shapes-definition/_index.html b/docs/shacl-tutorial/shacl-shapes-definition/_index.html index d30ba3dc..35356785 100644 --- a/docs/shacl-tutorial/shacl-shapes-definition/_index.html +++ b/docs/shacl-tutorial/shacl-shapes-definition/_index.html @@ -143,7 +143,7 @@
    @@ -162,7 +162,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/shacl-shapes-definition/_shape-target.html b/docs/shacl-tutorial/shacl-shapes-definition/_shape-target.html index aff3c1a5..4797c217 100644 --- a/docs/shacl-tutorial/shacl-shapes-definition/_shape-target.html +++ b/docs/shacl-tutorial/shacl-shapes-definition/_shape-target.html @@ -150,7 +150,7 @@
    @@ -211,7 +211,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
    diff --git a/docs/shacl-tutorial/shacl-shapes-definition/_validation-flow.html b/docs/shacl-tutorial/shacl-shapes-definition/_validation-flow.html index 030a8c36..8b51717f 100644 --- a/docs/shacl-tutorial/shacl-shapes-definition/_validation-flow.html +++ b/docs/shacl-tutorial/shacl-shapes-definition/_validation-flow.html @@ -150,7 +150,7 @@
    @@ -200,7 +200,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
    diff --git a/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html b/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html index 97acd855..8e1b4806 100644 --- a/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html +++ b/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html @@ -170,7 +170,7 @@
    @@ -707,7 +707,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/tutorial-example/grow-refine.html b/docs/shacl-tutorial/tutorial-example/grow-refine.html index 947632fd..05b4be99 100644 --- a/docs/shacl-tutorial/tutorial-example/grow-refine.html +++ b/docs/shacl-tutorial/tutorial-example/grow-refine.html @@ -153,7 +153,7 @@
    @@ -232,7 +232,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/tutorial-example/index.html b/docs/shacl-tutorial/tutorial-example/index.html index 31bfeb5f..c33fc422 100644 --- a/docs/shacl-tutorial/tutorial-example/index.html +++ b/docs/shacl-tutorial/tutorial-example/index.html @@ -169,7 +169,7 @@
    @@ -274,7 +274,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
    diff --git a/docs/shacl-tutorial/tutorial-example/little-publishing-domain.html b/docs/shacl-tutorial/tutorial-example/little-publishing-domain.html index 4e9eb63a..8b37ae80 100644 --- a/docs/shacl-tutorial/tutorial-example/little-publishing-domain.html +++ b/docs/shacl-tutorial/tutorial-example/little-publishing-domain.html @@ -152,7 +152,7 @@
    @@ -215,7 +215,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/tutorial-example/researcher.html b/docs/shacl-tutorial/tutorial-example/researcher.html index 00a01ad2..5b49c80b 100644 --- a/docs/shacl-tutorial/tutorial-example/researcher.html +++ b/docs/shacl-tutorial/tutorial-example/researcher.html @@ -143,7 +143,7 @@
    @@ -225,7 +225,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/shacl-tutorial/tutorial-example/start-simple.html b/docs/shacl-tutorial/tutorial-example/start-simple.html index 898b29c4..b75c3f64 100644 --- a/docs/shacl-tutorial/tutorial-example/start-simple.html +++ b/docs/shacl-tutorial/tutorial-example/start-simple.html @@ -170,7 +170,7 @@
    @@ -249,7 +249,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0 diff --git a/docs/tools/index.html b/docs/tools/index.html index cfb47040..3a112abd 100644 --- a/docs/tools/index.html +++ b/docs/tools/index.html @@ -143,7 +143,7 @@
    @@ -162,7 +162,7 @@

    -0.2.0+59-b5c3ecb2+20190329-1618 +0.2.0+63-1207c9f0
    diff --git a/index.html b/index.html index b2dc6438..20598268 100644 --- a/index.html +++ b/index.html @@ -1 +1 @@ - Neuroshapes | Open schemas for FAIR neuroscience data

    Neuroshapes

    Open schemas for FAIR neuroscience Data, Schemas and Vocabulary

    Why Neuroshapes?

    Motivation

    Modern scientific data management requires comprehensive support for the FAIR (Findable, Accessible, Interoperable, Reusable) principles. Neuroshapes is a general approach, or design pattern, for supporting FAIR principles for diverse neuroscience data with the following benefits:

    • Neuroshapes ensures that the key scientific and technical activities and agents of the data generation process are expressed in a validatable provenance-based data model.

    Neuroshapes captures the contextual information necessary to:

    • Interpret the scientific meaning of the data.
    • Infer the resulting data types.
    • Evaluate trust and quality.
    • Ensure attribution of all contributors.
    • Support data reuse, integration, interoperability and longevity.

    Goals

    The main goal is to provide design patterns, best practices as well as tools to promote:

    • The use of standard semantic markups and linked data principles as ways to structure metadata and related data.
    • The use of the W3C SHACL (Shapes Constraint Language) recommendation as a rich metadata schema language which is formal and expressive; interoperable; machine-readable; and domain-agnostic.
    • The reuse of existing schemas and semantic markups ( schema.org , W3C PROV-O ) and existing ontologies and controlled vocabularies (including NIFSTD - Neuroscience Information Framework Standard Ontologies).
    • The use of the W3C PROV-O recommendation as a format to record (meta)data provenance.

    Get Involved

    Join the INCF Neuroshapes Special Interest Group:

    This SIG aims to coordinate community efforts for the development of open, use case driven and shared validatable data models (schemas, vocabularies) to enable the FAIR principles (Findable, Accessible, Interoperable and Reusable) for basic, computational and clinical neuroscience (meta)data.

    How to Contribute

    Found a bug ? Want a new feature ?


    Get in Touch

    INCF SIG on Neuroshapes

    This SIG aims to coordinate community efforts for the development of open, use case driven and shared validatable data models (schemas, vocabularies) to enable the FAIR principles (Findable, Accessible, Interoperable and Reusable) for basic, computational and clinical neuroscience (meta)data.

    Acknowledgements

    This work has been supported by ETH Board funding to the Blue Brain Project. Portions of this work have also been supported by the European Union’s Horizon 2020 research and innovation programme under grant agreement no.720270. (Human Brain Project).

    Participants

    Sean Hill, Krembil Centre for Neuroinformatics, CAMH, Chair
    Andrew Davison, CNRS, Human Brain Project, Chair
    Anna-Kristin Kaufmann, EPFL, Blue Brain Project
    Huanxiang Lu, EPFL, Blue Brain Project
    Tom Gillespie, UCSD, Neuroscience Information Framework
    Genrich Ivaska, EPFL, Blue Brain Project
    Oliver Schmid, EPFL, Human Brain Project
    Jean-Denis Courcol, EPFL, Blue Brain Project
    Samuel Kerrien, EPFL, Blue Brain Project
    Jeff Muller, EPFL, Human Brain Project
    Mohameth François Sy, EPFL, Blue Brain Project, Co-Chair
    Bogdan Roman, EPFL, Blue Brain Project
    Pierre-Alexandre Fonta, EPFL, Blue Brain Project
    Coste Benoît Jean-Albert, EPFL, Blue Brain Project
    Taylor MacMillan, Krembil Centre for Neuroinformatics, CAMH
    David Rotenberg, Krembil Centre for Neuroinformatics, CAMH
    \ No newline at end of file + Neuroshapes | Open schemas for FAIR neuroscience data

    Neuroshapes

    Open schemas for FAIR neuroscience Data, Schemas and Vocabulary

    Why Neuroshapes?

    Motivation

    Modern scientific data management requires comprehensive support for the FAIR (Findable, Accessible, Interoperable, Reusable) principles. Neuroshapes is a general approach, or design pattern, for supporting FAIR principles for diverse neuroscience data with the following benefits:

    • Neuroshapes ensures that the key scientific and technical activities and agents of the data generation process are expressed in a validatable provenance-based data model.

    Neuroshapes captures the contextual information necessary to:

    • Interpret the scientific meaning of the data.
    • Infer the resulting data types.
    • Evaluate trust and quality.
    • Ensure attribution of all contributors.
    • Support data reuse, integration, interoperability and longevity.

    Goals

    The main goal is to provide design patterns, best practices as well as tools to promote:

    • The use of standard semantic markups and linked data principles as ways to structure metadata and related data.
    • The use of the W3C SHACL (Shapes Constraint Language) recommendation as a rich metadata schema language which is formal and expressive; interoperable; machine-readable; and domain-agnostic.
    • The reuse of existing schemas and semantic markups ( schema.org , W3C PROV-O ) and existing ontologies and controlled vocabularies (including NIFSTD - Neuroscience Information Framework Standard Ontologies).
    • The use of the W3C PROV-O recommendation as a format to record (meta)data provenance.

    Get Involved

    Join the INCF Neuroshapes Special Interest Group:

    This SIG aims to coordinate community efforts for the development of open, use case driven and shared validatable data models (schemas, vocabularies) to enable the FAIR principles (Findable, Accessible, Interoperable and Reusable) for basic, computational and clinical neuroscience (meta)data.

    How to Contribute

    Found a bug ? Want a new feature ?


    Get in Touch

    INCF SIG on Neuroshapes

    This SIG aims to coordinate community efforts for the development of open, use case driven and shared validatable data models (schemas, vocabularies) to enable the FAIR principles (Findable, Accessible, Interoperable and Reusable) for basic, computational and clinical neuroscience (meta)data.

    Acknowledgements

    This work has been supported by ETH Board funding to the Blue Brain Project. Portions of this work have also been supported by the European Union’s Horizon 2020 research and innovation programme under grant agreement no.720270. (Human Brain Project).

    Participants

    Sean Hill, Krembil Centre for Neuroinformatics, CAMH, Chair
    Andrew Davison, CNRS, Human Brain Project, Chair
    Anna-Kristin Kaufmann, EPFL, Blue Brain Project
    Huanxiang Lu, EPFL, Blue Brain Project
    Tom Gillespie, UCSD, Neuroscience Information Framework
    Genrich Ivaska, EPFL, Blue Brain Project
    Oliver Schmid, EPFL, Human Brain Project
    Jean-Denis Courcol, EPFL, Blue Brain Project
    Samuel Kerrien, EPFL, Blue Brain Project
    Jeff Muller, EPFL, Human Brain Project
    Mohameth François Sy, EPFL, Blue Brain Project, Co-Chair
    Bogdan Roman, EPFL, Blue Brain Project
    Pierre-Alexandre Fonta, EPFL, Blue Brain Project
    Coste Benoît Jean-Albert, EPFL, Blue Brain Project
    Taylor MacMillan, Krembil Centre for Neuroinformatics, CAMH
    David Rotenberg, Krembil Centre for Neuroinformatics, CAMH
    \ No newline at end of file diff --git a/paradox.json b/paradox.json index 38c7035d..bef6b2d6 100644 --- a/paradox.json +++ b/paradox.json @@ -1,4 +1,4 @@ { "name" : "Paradox Material Theme", - "version" : "0.2.0+59-b5c3ecb2+20190329-1618" + "version" : "0.2.0+63-1207c9f0" } \ No newline at end of file diff --git a/search/search_index.json b/search/search_index.json index a9b0cd80..d9feff8b 100644 --- a/search/search_index.json +++ b/search/search_index.json @@ -1 +1 @@ -{"docs":[{"location":"/paradox.json","text":"","title":""},{"location":"/docs/data-models/literature/literature.html","text":"","title":"Literature"},{"location":"/docs/data-models/literature/literature.html#literature","text":"","title":"Literature"},{"location":"/docs/data-models/literature/literature.html#use-cases","text":"List of use cases: TBD","title":"Use cases"},{"location":"/docs/data-models/literature/literatureannotation.html","text":"","title":"Literature Annotation"},{"location":"/docs/data-models/literature/literatureannotation.html#literature-annotation","text":"","title":"Literature Annotation"},{"location":"/docs/data-models/literature/literatureannotation.html#a-motivating-example","text":"","title":"A motivating example"},{"location":"/docs/data-models/literature/literatureannotation.html#description","text":"We want to be able to get, from a parameter type, all the data that are in the corpus. From this raw “dump”, we will use NAT for performing the various post-treatments to generate parameter aggregation. Parameter aggregations will need to be registered to Nexus and queried back from Nexus.","title":"Description"},{"location":"/docs/data-models/literature/literatureannotation.html#competency-questions","text":"Annotation: Get all annotations Get annotations by parameter type (labels ?) Get annotation by id Get annotation by article id (doi,…) Parameter: Get all parameters Get parameters by type Get parameters by annotation id","title":"Competency questions"},{"location":"/docs/data-models/literature/literatureannotation.html#abstract-data-model","text":"","title":"Abstract Data model"},{"location":"/docs/data-models/literature/annotation.html","text":"","title":"Annotation"},{"location":"/docs/data-models/literature/annotation.html#annotation","text":"","title":"Annotation"},{"location":"/docs/data-models/literature/annotation.html#use-cases","text":"List of use cases: TBD","title":"Use cases"},{"location":"/docs/data-models/literature/parameter.html","text":"","title":"Parameter"},{"location":"/docs/data-models/literature/parameter.html#parameter","text":"","title":"Parameter"},{"location":"/docs/data-models/literature/parameter.html#use-cases","text":"List of use cases: TBD","title":"Use cases"},{"location":"/docs/data-models/literature/provenance.html","text":"","title":"Provenance"},{"location":"/docs/data-models/literature/provenance.html#provenance","text":"","title":"Provenance"},{"location":"/docs/data-models/literature/provenance.html#use-cases","text":"List of use cases: TBD","title":"Use cases"},{"location":"/docs/data-models/literature/neuronclassification.html","text":"","title":"Literature Annotation"},{"location":"/docs/data-models/literature/neuronclassification.html#literature-annotation","text":"","title":"Literature Annotation"},{"location":"/docs/data-models/literature/neuronclassification.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/literature/neuronclassification.html#description","text":"Axon projection M-type\nSteps: - Get all cell types","title":"Description"},{"location":"/docs/data-models/literature/neuronclassification.html#competency-questions","text":"","title":"Competency questions"},{"location":"/docs/data-models/literature/neuronclassification.html#abstract-data-model","text":"","title":"Abstract Data model"},{"location":"/docs/shacl-tutorial/nexus-kg-schemas/_nexus-shacl-schemas.html","text":"","title":"Namespaces and Context"},{"location":"/docs/shacl-tutorial/nexus-kg-schemas/_nexus-shacl-schemas.html#namespaces-and-context","text":"\"@context\" : {\n \"class\" : {\n \"@id\" : \"sh:class\",\n \"@type\" : \"@id\"\n },\n \"rootClass\" : {\n \"@id\" : \"shext:rootClass\",\n \"@type\" : \"@id\"\n },\n \"path\" : {\n \"@id\" : \"sh:path\",\n \"@type\" : \"@id\"\n },\n \"qualifiedValueShape\" : {\n \"@id\" : \"sh:qualifiedValueShape\",\n \"@type\" : \"@id\",\n \"@container\" : \"@list\"\n },\n \"qualifiedValueShapesDisjoint\" : {\n \"@id\" : \"sh:qualifiedValueShapesDisjoint\",\n \"@type\" : \"xsd:boolean\"\n },\n \"qualifiedMinCount\" : {\n \"@id\" : \"sh:qualifiedMinCount\",\n \"@type\" : \"xsd:integer\"\n },\n \"qualifiedMaxCount\" : {\n \"@id\" : \"sh:qualifiedMaxCount\",\n \"@type\" : \"xsd:integer\"\n },\n \"maxCount\" : {\n \"@id\" : \"sh:maxCount\",\n \"@type\" : \"xsd:integer\"\n },\n \"minCount\" : {\n \"@id\" : \"sh:minCount\",\n \"@type\" : \"xsd:integer\"\n },\n \"minInclusive\" :\"sh:minInclusive\",\n \"maxInclusive\" :\"sh:maxInclusive\",\n \"maxExclusive\" :\"sh:maxExclusive\",\n \"minExclusive\" :\"sh:minExclusive\",\n \"in\" : {\n \"@id\" : \"sh:in\",\n \"@container\" : \"@list\"\n },\n \"imports\" : {\n \"@id\" : \"owl:imports\",\n \"@type\" : \"@id\",\n \"@container\" : \"@set\"\n },\n \"datatype\" : {\n \"@id\" : \"sh:datatype\",\n \"@type\" : \"@id\"\n },\n \"description\" : \"sh:description\",\n \"name\" : \"sh:name\",\n \"nodeKind\" : {\n \"@id\" : \"sh:nodeKind\",\n \"@type\" : \"@id\"\n },\n \"node\" : {\n \"@id\" : \"sh:node\",\n \"@type\" : \"@id\"\n },\n \"property\" : {\n \"@id\" : \"sh:property\",\n \"@type\" : \"@id\",\n \"@container\" : \"@set\"\n },\n \"targetClass\" : {\n \"@id\" : \"sh:targetClass\",\n \"@type\" : \"@id\"\n },\n \"targetObjectsOf\" : {\n \"@id\" : \"sh:targetObjectsOf\",\n \"@type\" : \"@id\"\n },\n \"targetSubjectsOf\" : {\n \"@id\" : \"sh:targetSubjectsOf\",\n \"@type\" : \"@id\"\n },\n \"isDefinedBy\" : {\n \"@id\" : \"http://www.w3.org/2000/01/rdf-schema#isDefinedBy\",\n \"@type\" : \"@id\"\n },\n \"shapes\" : {\n \"@reverse\" : \"http://www.w3.org/2000/01/rdf-schema#isDefinedBy\",\n \"@type\" : \"@id\",\n \"@container\" : \"@set\"\n },\n \"or\" : {\n \"@id\" : \"sh:or\",\n \"@type\" : \"@id\",\n \"@container\" : \"@list\"\n },\n \"and\" : {\n \"@id\" : \"sh:and\",\n \"@type\" : \"@id\",\n \"@container\" : \"@list\"\n },\n \"xone\" : {\n \"@id\" : \"sh:xone\",\n \"@type\" : \"@id\",\n \"@container\" : \"@list\"\n },\n \"not\" : {\n \"@id\" : \"sh:not\",\n \"@type\" : \"@id\",\n \"@container\" : \"@list\"\n },\n \"lessThan\": {\n \"@id\" : \"sh:lessThan\",\n \"@type\" : \"@id\"\n },\n \"hasValue\" :\"sh:hasValue\",\n \"owl\" : \"http://www.w3.org/2002/07/owl#\",\n \"rdf\" : \"http://www.w3.org/1999/02/22-rdf-syntax-ns#\",\n \"rdfs\" : \"http://www.w3.org/2000/01/rdf-schema#\",\n \"xsd\" : \"http://www.w3.org/2001/XMLSchema#\",\n \"sh\" : \"http://www.w3.org/ns/shacl#\",\n \"shext\" : \"http://www.w3.org/ns/shacl/ext#\",\n \"schema\" : \"http://schema.org/\",\n\n }\nWithin this document, the following prefix mappings are used:\nPrefix Name Namespace sh http://www.w3.org/ns/shacl# rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs http://www.w3.org/2000/01/rdf-schema# owl http://www.w3.org/2002/07/owl# xsd http://www.w3.org/2001/XMLSchema# prov http://www.w3.org/ns/prov# shext http://www.w3.org/ns/shacl/ext# schema http://schema.org/ bbp https://bbp-nexus.epfl.ch/ns#\nNote that the 'bbp' namespace is used in this document as an example namespace.\nBy convention all shapes defined in a SHACL schema are prefixed by this.\nPrefix Name Namespace this {endpoint}/schemas/{org}/{domain}/{schema_name}/{version}/shapes/\nTo improve readability and to simplify the examples, the SHACL context described in the right is used for all the SHACL JSON-LD serialization presented in this document. This default context is only related to the SHACL vocabulary and should be used in all schemas. Since writing a SHACL schema almost always required to use a domain vocabulary, domain context can be added when needed. In all cases, the context object is omitted in the examples below. It needs to be added to make the examples work.","title":"Namespaces and Context"},{"location":"/docs/shacl-tutorial/nexus-kg-schemas/_nexus-shacl-schemas.html#shacl-schemas","text":"{\n \"@id\" : \"{endpoint}/schemas/{org}/{domain}/{schema_name}/{version}/\",\n \"@type\":\"owl:Ontology\",\n \"shapes\" : [{\n \"@id\" : \"this:{shapeName}\",\n \"@type\":\"sh:Shape\"\n },{\n \"@id\" : \"this:{anotherShapeName}\",\n \"@type\":\"sh:Shape\"\n }]\n}\nIn Nexus Knowledge Graph (KG), a schema:\nis identified by a URI consistent with the following pattern: {endpoint}/schemas/{org}/{domain}/{schema_name}/{version}/, is an ontology: it has owl:Ontology as type defines a collection of a collection of shapes; the objects in the shapes array. The ‘shapes’ key is defined as a reverse property of rdfs:isDefinedBy\nNote that the W3C SHACL recommendation only defines SHACL shapes and doesn't define particular ways of wrapping them together.\nFrom this point, a Nexus KG schema will be indifferently referred to as a SHACL schema or just schema.\nWrapping shapes together in a schema allows us to (among other things):\ngive an identifier to a collection of shapes attach annotations to the schema import vocabularies and/or ontologies import other schemas for reuse purpose\nA schema can then be seen here as an envelop for shapes exchange.","title":"SHACL schemas"},{"location":"/docs/shacl-tutorial/overview/_why-shacl.html","text":"","title":"Why SHACL ?"},{"location":"/docs/shacl-tutorial/overview/_why-shacl.html#why-shacl-","text":"","title":"Why SHACL ?"},{"location":"/docs/data-models/ngv/molecule.html","text":"","title":"title"},{"location":"/docs/data-models/ngv/molecule.html#title","text":"","title":"title"},{"location":"/docs/data-models/ngv/molecule.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/ngv/molecule.html#description","text":"Description of type of molecules like protein refereing external databases.","title":"Description"},{"location":"/docs/data-models/ngv/molecule.html#competency-questions-to-be-completed-","text":"The following points describe a subset of questions :\nGet the reactions in a given pathway","title":"Competency questions (to be completed)"},{"location":"/docs/data-models/ngv/molecule.html#entities","text":"The different entity types involved are described below.\nType Description Reaction description Pathway description","title":"Entities"},{"location":"/docs/data-models/ngv/molecule.html#activities","text":"The different activity types involved are described below.\nType Description Activity description","title":"Activities"},{"location":"/docs/data-models/ngv/molecule.html#agents","text":"The different agent types involved are described below.\nType Description Agent description","title":"Agents"},{"location":"/docs/shacl-tutorial/overview/validation-flow-old.html","text":"","title":"Validation flow"},{"location":"/docs/shacl-tutorial/overview/validation-flow-old.html#validation-flow","text":"Data validation using a SHACL processor involves two type of resources:\na shape defining the constraints the data should conform to: the shape is called shapes graph in the W3C SHACL recommendation. the data to be validated against the shape: called data graph in the W3C SHACL recommendation\nGiven a shape and a data as inputs, a SHACL processor starts by selecting what part of the data to focus on and then validate whether that part conforms to the shape graph or not.","title":"Validation flow"},{"location":"/docs/shacl-tutorial/overview/validation-flow-old.html#data-selection","text":"A shape can specify the nodes it will validate within a data graph by using one or many target declarations. A shape can target:\na specific node What to validate What to validate What to validate\nThe target declarations section provides in depth explanation about the different ways for a shape to select a node to validate.\nBut why does a target selection mechanism needed ? Why isn’t all the data graph validated against a shape? The answer lies in the graph nature of json-ld data structure in which there is no root node. Which node is the root or the ‘main’ one in the following example showing a description of the professor Jane Doe ? Is it the node Jane Doe or EPFL ?\nis a graph data model and as such does not have SHACL starts by selecting nodes in the data graph targeted by each shape in the shapes graph. The selected nodes are called focused nodes.\nShapes need to declare the node target the nodes they should validate because of the graph nature of JSON-LD: there is no root in a graph data model. 2 s A target","title":"Data selection"},{"location":"/docs/shacl-tutorial/overview/validation-flow-old.html#data-filtering","text":"Filters can be used to eliminate some focused nodes","title":"Data filtering"},{"location":"/docs/shacl-tutorial/overview/validation-flow-old.html#data-validation","text":"","title":"Data validation"},{"location":"/docs/data-models/minds/namespace.html","text":"","title":"Namespace"},{"location":"/docs/data-models/minds/namespace.html#namespace","text":"List of use cases: TBD","title":"Namespace"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html","text":"","title":"Best Practices"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#best-practices","text":"","title":"Best Practices"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#node-shapes-identifiers","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/CircuitShape\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"property\":[{\n \"@id\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/ConnectomeShape\",\n \"path\": \"bbpprodprop:connectome\"\n \"name\": \"Connectome\",\n \"description\": \"Connectome\",\n \"datatype\": \"xsd:string\",\n \"maxCount\": 1,\n \"minCount\": 0\n }\n ]\n }\n ]\n}\nIt is strongly recommended to provide identifiers (value for @id) for the node shapes (things of type sh:NodeShape) so that they can be reused and discovered through the Nexus Rest API.\nBoth node shapes and property shapes can have identifiers.\nA property shape needs to have an identifier only if there is a need to reuse it.","title":"Node shapes identifiers"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#nexus-schema-annotations","text":"Schemas are often designed with reuse in mind. Good annotations is key in order to enable schema discoverability and reuse. The following list presents a set of recommended annotations that one can use to describe a schema:\n…WIP","title":"Nexus schema annotations"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#shape-annotations","text":"","title":"SHAPE annotations"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#node-shape-annotations","text":"Node shapes are shapes with type sh:NodeShape. It is recommended that a node shape is annotated with the following properties:\nKey Description label A human readable label for the node shape. This property is a short form for rdfs:label. comment A human readable description of the node shape.This property is a short form for rdfs:comment.","title":"Node shape annotations"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#property-shape-annotations","text":"Property shapes are shapes with type sh:PropertyShape. It is recommended that a property shape is annotated with the following properties:\nKey Description name A human readable name for the shape. The name is usually displayed when a form is generated from the shape description A human readable description of the shape. Also used in form generation\nAnnotation properties are not taken into accoiunt during validation.","title":"Property shape annotations"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#shape-keys-ordering","text":"To improve the SHACL schema readability, it is recommended to adopt the following ordering when defining:\na Node Shape\nOrder Key Description 1 @id Always start with the node shape identifier if any 2 @type The node shape type 3 label A human readable description of the node shape. 4 comment A description of the node shape. 5 target(Class-Node-ObjectsOf-SubjectsOf) The node shape target 6 nodeKind The node shape node kind 7 property The node shape properties\na Property Shape\nOrder Key Description 1 @id Always start with the property shape identifier if any. Most of the time, there is no need to have an identifier for a property shape 2 @type The property shape type. Most of the time, there is no need to add a type to a property shape 3 path The property targeted by the property shape. 4 name A human readable name for the property shape. 5 description A human readable description of the property shape. 6 nodeKind The property shape node kind. Cannot be present when datatype is present. 7 class or datatype These two keys are mutually exclusive. THus they can occurs in the same property shape at the same time. Every value of the targeted property (defined in path) should have the value of class or datatype as type 8 node Always has a node shape as value. Every value of the targeted property (defined in path) should conform to the referenced node shape. 9 minCount or maxCount Cardinality constraints.","title":"SHAPE keys ordering"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#naming-conventions","text":"","title":"Naming conventions"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#class-name-as-single-noun","text":"In schemas, classes (values of targetClass, of @type) are named using camel case notation:\nclass name should start with a capital letter class name should be singular no space is allowed good examples: “bbp:Circuit”, bbp:RawMorphology bad examples: “bbp:Circuits”, “bbp:circuit” but also “bbp:Raw_Morphology”","title":"Class name as single noun"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#instance-name-as-single-noun","text":"Instances naming follows the same conventions as class naming. In a schemas, instances are things that have a type (@type): mainly the shapes (node and property shapes).","title":"Instance name as single noun"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#property-name-as-verb-sense-or-single-noun","text":"In schemas, properties (mainly values of sh:path) are named using the following convention:\nproperty name should start with lower case and be capitalized thereafter property name should be singular no space is allowed good example: “bbp:morphology”, “bbp:hasFileExtension” or “bbp:fileExtension” bad examples: “bbp:morphologies” but also “bbp:segment_index”","title":"Property name as verb sense or single noun"},{"location":"/docs/tools/index.html","text":"","title":"Software and Tools"},{"location":"/docs/tools/index.html#software-and-tools","text":"","title":"Software and Tools"},{"location":"/docs/shacl-tutorial/overview/shape-target.html","text":"","title":"Target declaration"},{"location":"/docs/shacl-tutorial/overview/shape-target.html#target-declaration","text":"Because graph like RDF does not have root node.\nA shape can define the nodes it will select and validate in a given data graph. It does so by declaring a target. Four different target declarations exist in SHACL as described in the following sections:\nNode target using the key targetNode Class target using the key targetClass Property Subject target using the key targetSubjectsOf Property Object target using the key targetObjectsOf\nNote that selected nodes for every target below are identified by a green line color.","title":"Target declaration"},{"location":"/docs/shacl-tutorial/overview/shape-target.html#node-target","text":"A shape can target very specific instances (nodes) by specifying their URIs through a targetNode:\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/Circuit_1_2\",\n \"@type\" : \"sh:NodeShape\",\n \"targetNode\" : [\"bbp:Circuit_1\",\"bbp:Circuit_2\"]\n } ]\n}\nThe instances identified by bbp:Circuit_1 and bbp:Circuit_2 are targeted in the figure above.","title":"Node target"},{"location":"/docs/shacl-tutorial/overview/shape-target.html#class-target","text":"The following schema defines one node shape which targets all instances of the class bbp:Entity. So only nodes that has bbp:Entity as direct type (**bb:Entity_1**) or indirect type (**bbp:Circuit_1** and bbp:Circuit_2) will be validated while all the other nodes are ignored.\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/Entity\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Entity\"\n } ]\n}","title":"Class target"},{"location":"/docs/shacl-tutorial/overview/shape-target.html#property-object-target","text":"A shape can target nodes that are objects of a specific property through targetObjectsOf.\nThis target will select any node that participate to the following triple as object: (subject, property, SelectedNode). In the figure below, there are two selected nodes (**bbp:Morphology_1** and bbp:Morphology_2) which respectively participate to the following two triples:\n*(bbp:Circuit_1, bbp:morphology, bbp:Morphology_1) *(bbp:Circuit_2, bbp:morphology, bbp:Morphology_2)\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertyObject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetObjectsOf\" : \"bbp:morphology\"\n } ]\n}","title":"Property Object target"},{"location":"/docs/shacl-tutorial/overview/shape-target.html#property-subject-target","text":"This target is the subject counterpart of the previous one. A shape can target nodes that are subjects of a specific property through targetSubjectsOf. So any nodes that are subjects of a triple with the target property as predicate will be selected: (**SelectedNode**, property, object).\nIn the figure below, there are two selected nodes (**bbp:Circuit_1** and bbp:Circuit_2) which respectively participate to the following two triples:\n(**bbp:Circuit_1**, bbp:morphology, bbp:Morphology_1) (**bbp:Circuit_2**, bbp:morphology, bbp:Morphology_2)\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertySubject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetSubjectsOf\" : \"bbp:morphology\"\n } ]\n}","title":"Property Subject target"},{"location":"/docs/datamodeling/linkeddata/index.html","text":"","title":"Thinking in Linked Data"},{"location":"/docs/datamodeling/linkeddata/index.html#thinking-in-linked-data","text":"test test test test tst test est","title":"Thinking in Linked Data"},{"location":"/docs/data-models/minds/taxonomy.html","text":"","title":"Taxonomy"},{"location":"/docs/data-models/minds/taxonomy.html#taxonomy","text":"List of use cases: TBD","title":"Taxonomy"},{"location":"/docs/data-models/minds/model.html","text":"","title":"Abstract Data Model"},{"location":"/docs/data-models/minds/model.html#abstract-data-model","text":"List of use cases: TBD","title":"Abstract Data Model"},{"location":"/docs/data-models/minds/minds.html","text":"","title":"MINDS"},{"location":"/docs/data-models/minds/minds.html#minds","text":"","title":"MINDS"},{"location":"/docs/data-models/minds/minds.html#overview","text":"Put the abstract model here","title":"Overview"},{"location":"/docs/data-models/minds/minds.html#competency-questions","text":"The questions this model address","title":"Competency questions"},{"location":"/docs/data-models/minds/minds.html#schemas","text":"Vocabulary and constraints. Give an overview here and link towards","title":"Schemas"},{"location":"/docs/data-models/minds/minds.html#ontologies","text":"Recommended ontologies to use","title":"Ontologies"},{"location":"/docs/data-models/minds/minds.html#taxonomies","text":"Recommended taxonomies to use","title":"Taxonomies"},{"location":"/assets/provtemplates/README.html","text":"","title":"Provenance Templates"},{"location":"/assets/provtemplates/README.html#provenance-templates","text":"","title":"Provenance Templates"},{"location":"/assets/contexts/nexus/core/shacl20170720/prefixmapings.html","text":"Prefix Name Namespace sh http://www.w3.org/ns/shacl# shsh http://www.w3.org/ns/shacl-shacl# rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs http://www.w3.org/2000/01/rdf-schema# owl http://www.w3.org/2002/07/owl# xsd http://www.w3.org/2001/XMLSchema# prov http://www.w3.org/ns/prov# skos http://www.w3.org/2004/02/skos/core# schema http://schema.org/ nxv https://bbp-nexus.epfl.ch/vocabs/nexus/core/terms/v0.1.0/ nsg https://bbp-nexus.epfl.ch/vocabs/bbp/neurosciencegraph/core/v0.1.0/ ex http://example.org/","title":""},{"location":"/docs/data-models/ngv/new.html","text":"","title":"title"},{"location":"/docs/data-models/ngv/new.html#title","text":"","title":"title"},{"location":"/docs/data-models/ngv/new.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/ngv/new.html#description","text":"This specification describes metadata","title":"Description"},{"location":"/docs/data-models/ngv/new.html#competency-questions-to-be-completed-","text":"The following points describe a subset of questions :\nGet the reactions in a given pathway","title":"Competency questions (to be completed)"},{"location":"/docs/data-models/ngv/new.html#entities","text":"The different entity types involved are described below.\nType Description Reaction description Pathway description","title":"Entities"},{"location":"/docs/data-models/ngv/new.html#activities","text":"The different activity types involved are described below.\nType Description Activity description","title":"Activities"},{"location":"/docs/data-models/ngv/new.html#agents","text":"The different agent types involved are described below.\nType Description Agent description","title":"Agents"},{"location":"/docs/publication/index.html","text":"","title":"Publications"},{"location":"/docs/publication/index.html#publications","text":"","title":"Publications"},{"location":"/docs/shacl-tutorial/overview/validation-flow.html","text":"","title":"Validation flow"},{"location":"/docs/shacl-tutorial/overview/validation-flow.html#validation-flow","text":"Data validation using a SHACL processor involves two type of resources:\na shape defining the constraints the data should conform to: the shape is called shapes graph in the W3C SHACL recommendation. the data to be validated against the shape: called data graph in the W3C SHACL recommendation\nGiven a shape and a data as inputs, a SHACL processor starts by selecting what part of the data to focus on and then validate whether that part conforms to the shape graph or not.","title":"Validation flow"},{"location":"/docs/shacl-tutorial/overview/validation-flow.html#data-selection","text":"A shape can specify the nodes it will validate within a data graph by using one or many target declarations. A shape can target:\na specific node nodes of a given type nodes that are subject of a given property nodes that are object of a given property","title":"Data selection"},{"location":"/docs/shacl-tutorial/overview/validation-flow.html#data-validation","text":"When focused nodes to validate against a shape are identified then the validation can occurs. A SHACL processor will check if a node conform to the constraints defined in a shape that selects it. A validation report is produced at the end.\nShwo example.","title":"Data validation"},{"location":"/docs/data-models/minds/ontology.html","text":"","title":"Ontology"},{"location":"/docs/data-models/minds/ontology.html#ontology","text":"List of use cases: TBD","title":"Ontology"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html","text":"","title":"What is SHACL ?"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#what-is-shacl-","text":"","title":"What is SHACL ?"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#reference-documentation","text":"","title":"Reference documentation"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#context-and-namespaces","text":"","title":"Context and Namespaces"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#validation-flow","text":"How a shape works?\nGiven an input RDF data graph (a json-ld document):\nNode to be focused on for validation are selected using targets Filters can be used to eliminate some focused nodes Validate focused using constraints","title":"Validation flow"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#target-declaration","text":"A shape can define the nodes it will select and validate in a given data graph. It does so by declaring a target. Four different target declarations exist in SHACL as described in the following sections:\nNode target using the key targetNode Class target using the key targetClass Property Subject target using the key targetSubjectsOf Property Object target using the key targetObjectsOf\nNote that selected nodes for every target below are identified by a green line color.","title":"Target declaration"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#node-target","text":"A shape can target very specific instances (nodes) by specifying their URIs through a targetNode:\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/Circuit_1_2\",\n \"@type\" : \"sh:NodeShape\",\n \"targetNode\" : [\"bbp:Circuit_1\",\"bbp:Circuit_2\"]\n } ]\n}\nThe instances identified by bbp:Circuit_1 and bbp:Circuit_2 are targeted in the figure above.","title":"Node target"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#class-target","text":"The following schema defines one node shape which targets all instances of the class bbp:Entity. So only nodes that has bbp:Entity as direct type (**bb:Entity_1**) or indirect type (**bbp:Circuit_1** and bbp:Circuit_2) will be validated while all the other nodes are ignored.\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/Entity\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Entity\"\n } ]\n}","title":"Class target"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#property-object-target","text":"A shape can target nodes that are objects of a specific property through targetObjectsOf.\nThis target will select any node that participate to the following triple as object: (subject, property, SelectedNode). In the figure below, there are two selected nodes (**bbp:Morphology_1** and bbp:Morphology_2) which respectively participate to the following two triples:\n*(bbp:Circuit_1, bbp:morphology, bbp:Morphology_1) *(bbp:Circuit_2, bbp:morphology, bbp:Morphology_2)\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertyObject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetObjectsOf\" : \"bbp:morphology\"\n } ]\n}","title":"Property Object target"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#property-subject-target","text":"This target is the subject counterpart of the previous one. A shape can target nodes that are subjects of a specific property through targetSubjectsOf. So any nodes that are subjects of a triple with the target property as predicate will be selected: (**SelectedNode**, property, object).\nIn the figure below, there are two selected nodes (**bbp:Circuit_1** and bbp:Circuit_2) which respectively participate to the following two triples:\n(**bbp:Circuit_1**, bbp:morphology, bbp:Morphology_1) (**bbp:Circuit_2**, bbp:morphology, bbp:Morphology_2)\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertySubject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetSubjectsOf\" : \"bbp:morphology\"\n } ]\n}","title":"Property Subject target"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#constraints","text":"A shape can defined a set of constraints to be checked against selected nodes. The set of possible constraints can be divided into two categories:\nNodeKind constraint: about selected nodes themselves Property constraints: about outgoing or incoming properties of each selected node","title":"Constraints"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#nodekind-constraint","text":"The nodeKind constraint allows to choose if a selected need to be identified by an IRI eventually consistent with a specific pattern or if it can unidentified. At most one nodeKind constraint can be defined for a given NodeShape.\nThe following schema states that all values of the property bbp:morphology have to be nodes identified by IRIs.\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertyObject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetObjectsOf\" : \"bbp:morphology\",\n \"nodeKind\": \"sh:IRI\"\n } ]\n}\nIn the previous example, the node “Morphology_1” (red border) is an object of the property bbp:morphology which is a Literal (precisely a string literal). So it’s not identifier by an IRI which makes it invalid. The node bbp:Morphology_2 (green border) on the other hand is valid because it is an object property of the property bbp:morphology and is identified by an IRI. All values of the nodeKind constraint are listed in the table below:\nValue Description sh:IRI The selected nodes have to be identified by a valid IRI. sh:BlankNode The selected nodes should not be identified by an IRI nor be a Literal. sh:Literal The selected nodes should be a Literal. sh:BlankNodeOrIRI Disjunctive combination of sh:BlankNode and sh:IRI. sh:BlankNodeOrLiteral Disjunctive combination of sh:BlankNode and sh:Literal. sh:IRIOrLiteral Disjunctive combination of sh:IRI and sh:Literal.","title":"NodeKind Constraint"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#property-constraints","text":"Definition of bbp:morphology as an outgoing property of any instance of bbp:Circuit:\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\"\n }\n } ]\n ]\n}\nGiven a selected node, a shape defines a set of outgoing and/or incoming properties as well as a set of constraints for each of them. By doing so, a shape enforce a vocabulary (a set of properties) to be used for describing the selected nodes (instances of bbp:Circuit in the schema for example) and how that vocabulary should be used (constraints).\nTo define a set of incoming and/or outgoing properties, the property key is used. It is an array and each of its item is an instance of a PropertyShape. The following tables describe the minimal keys to use in order to define a property:\nkey Description path MAandatory. Refers to the property IRI (“bbp:morphology” in the schema example) in case of outgoing property. For an incoming one, the following syntax is used: “path” : [ “sh:inversePath prov:generated” ]. name Optional. A human readable name of the property. The name can be used in generated forms for example. description Optional. Description of the property.\nOnce the property shape is defined, a set of constraints can be attached to it.\nCardinality Constraints\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:dataSpace\",\n \"name\" : \"Data Space\",\n \"description\" : \"Data Space.\",\n \"minCount\":\"1\"\n }\n ]\n }\n ]\n}\nHow many outgoing “bbp:morphology” properties a specific bbp:Circuit instance can have ? A question that can be reformulated as: how many triples following the pattern (bbp:Circuit_*, bbp:morphology, object) can exist in the data graph ? The answers can be: zero or more, exactly one, at most one. To enforce one of these answers a cardinality constraint can be defined and attached to a property shape as shown in the schema example. The default value for minCount and maxCount is 0.\nThe example schema states that all instances of bbp:Circuit should have at least one value for bbp:morphology property and at most 3 values. They should have at least one value for bbp:dataSpace property as well. In the example data graph below, bbp:Circuit_1 is valid because it has one value for bbp:morphology property and one value for bbp:dataSpace. On the other hand, bbp:Circuit_2 is not valid because it has not a value for bbp:dataSpace property.\nProperty Value Type Constraints\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:dataSpace\",\n \"name\" : \"Data Space\",\n \"description\" : \"Data Space.\",\n \"minCount\":\"1\"\n },\n {\n \"path\" : \"bbp:brainRegion\",\n \"name\" : \"Brain region\",\n \"description\" : \"Brain region.\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\",\n \"node\": \"circuitshape:LabeledOntologyTermShape\"\n },\n {\n \"path\" : \"schema:name\",\n \"name\" : \"Name\",\n \"description\" : \"Circuit name\",\n \"datatype\": \"xsd:string\",\n \"minCount\":\"1\",\n \"maxCount\":\"1\"\n }\n ]\n },\n {\n \"@id\" : \"circuitshape:LabeledOntologyTermShape\",\n \"@type\" : \"sh:NodeShape\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"rdfs:label\",\n \"name\" : \"label\",\n \"description\" : \"Human readable label\",\n \"datatype\": \"xsd:string\",\n \"maxCount\" : 1,\n \"minCount\" : 1\n\n }\n }\n ]\n}\nThe type of a property value can be restricted. In the schema example, all instances of bbp:circuit should have exactly one name which should be of type string. How to express such type restriction in a shacl schema ?\nPrimitive type as property value\nA property value can be of a primitive type: string, integer, double, anyURI, … and datatype key is used to define such primitive expected types as shown in the shacl schema example. The namespace of all primitive types is xsd and for a complete list of those types please check here.\nProperty values are not always primitive and two other typical situations may occurs.\nReference as property value\nThe type of a property value can be restricted to be an instance of a specific class. For example, it may be useful to enforce all values of the bbp:morphology property of a given circuit to be of type bbp:Morphology. To express this type of constraint the key class is used as shown in the schema example. The ability to constraint types is important to ensure the quality and reliability of the data being submitted into the Nexus platform and SHACL allows to do that without writing a single line of validation code.\nNode as property value\nSometimes it may be useful to enforce that a property value has a particular shape instead of being of a specific type. For example, we may want to enforce all brain region values of a all circuits (instances of bbp:Circuit) to have at least an IRI as identifier (“nodeKind”: “sh:IRI”) and a label as human readable description. The key node is used to express a shape constraint.","title":"Property Constraints"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#qualified-cardinality","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"3\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:morphology\",\n \"qualifiedValueShape\": {\n \"class\" : \"bbp:RawMorphology\"\n },\n \"qualifiedValueShapesDisjoint\": true,\n \"qualifiedMinCount\":1,\n \"qualifiedMaxCount\":1\n },\n {\n \"path\" : \"bbp:morphology\",\n \"qualifiedValueShape\": {\n \"class\" : \"bbp:SynthesizedMorphology\"\n },\n \"qualifiedValueShapesDisjoint\": true,\n \"qualifiedMinCount\":1\n }\n ]\n }\n ]\n}\nCardinality constraints can be more complex than what is presented in the constraints section above. A complex cardinality use case can be expressed in the following way : *a bbp:Circuit instance should be linked with exactly 3 Morphologies (instances of bbp:Morphology) *exactly one of them should be a raw morphology (an instance of bbp:RawMorphology) *at least one of them should be synthesized morphology (an instance of bbp:SynthesizedMorphology) *and a bbp:Circuit instance can’t be at the same time of type bbp:RawMorphology and bbp:SynthesizedMorphology\nThe schema example shows how to implement the above constraints using the following keys:\nkey Description qualifiedValueShape Mandatory. The shape that the specified (through qualifiedMinCount and qualifiedMaxCount) number of nodes should be consistent with. qualifiedMinCount Mandatory. The minimum number of nodes that should be consistent with the shape in qualifiedValueShape qualifiedMaxCount Mandatory. The maximum number of nodes that should be consistent with the shape in qualifiedValueShape qualifiedValueShapesDisjoint Optional. If true then the values conform to the current property shape must not conform to the siblings property shapes","title":"Qualified Cardinality"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#combining-shapes","text":"Until now we’ve described how to define a shape that targets different nodes using different selectors and enforcing different type of constraints. But designing real life schemas is complex and often required reuse of already defined ones. Two use cases can occur when it comes to reuse SHACL schemas:\nreuse a shape by combining it with other shapes using boolean operators specialization mechanism between shapes","title":"Combining shapes"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#logical-combination-of-shapes","text":"A node shape definition for all instances of bbp:Entity\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"this:EntityShape\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Entity\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [{\n \"path\" : \"schema:name\",\n \"name\" : \"Name\",\n \"description\" : \"Entity name\",\n \"or\":[\n {\n \"datatype\": \"xsd:string\"\n },\n {\n \"datatype\": \"xsd:integer\"\n }\n ]\n },{\n \"path\" : \"schema:description\",\n \"name\" : \"Description\",\n \"description\" : \"The entity description\",\n \"datatype\" : \"xsd:string\"\n }\n ]\n }\n ]\n}\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"@type\": \"owl:Ontology\",\n \"imports\" : [ \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\"],\n \"shapes\" : [ {\n \"@id\" : \"this:Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"and\":[{\n \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\"\n },\n {\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n }\n ]\n }\n ]\n }\n ]\n}\nShapes can be combined using the following boolean operators:\nkey Description and The data has to be valid with respect to all combined shapes or The data has to be valid with respect to at least one shape xone The data has to be valid with respect to only one shape not The data should not be valid with respect to the given shape(s)\nIn the previous schema (identified by {endpoint}/schemas/bbp/simulation/circuit/v1.0.0/), the property shape related to schema:name property can be externalized in a schema ({endpoint}/schemas/bbp/core/entity/v1.0.0/) belonging to the “bbp” organization, “core” domain and named “entity” as shown in the right tab. Now let reuse (see in the right) the entity schema since a bbp:Circuit is a bbp:Entity as well. Basically, the schema is expressing that a bbp:Circuit instance should be consistent with respect to the schema for bbp:Entity (external one) and the one for bbp:Circuit (local one).\nNote the use of the **imports** key. It tells the shacl validator where to find the shapes that are referenced in the local schema: \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\" for example. Only published schemas can be imported.\nThe or, xone and not operators can be used in the same way as the and one. The example shows how to logically combined two node shapes. Property shapes can be combined as well as shown in the shape this:EntityShape where the property schema:name van be of type string of integer.\nAll shapes that are listed in the shapes array are by default considered combined in conjunctive way (and operator).","title":"Logical combination of shapes"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#shape-specialization","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"@type\": \"owl:Ontology\",\n \"imports\" : [ \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\"],\n \"shapes\" : [ {\n \"@id\" : \"this:Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"and\":[{\n \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\"\n },\n {\n \"property\" : [\n {\n \"path\" : \"schema:description\",\n \"minCount\" : 1\n \"maxCount\" : 1\n },\n {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n }\n ]\n }\n ]\n }\n ]\n}\nIn the previous section, the circuit schema example already introduces a bit the way a shape can be specialized. Indeed combining shapes using the and boolean operator conveys a sense of extension. But the specialization can go further than just adding more constraints on top of a reused schema. The this:Circuit can further constraint the use of the schema:description property in all bbp:Circuit instances by setting a minimal and a mawimal cardinality. All bbp:Circuit instances must have exactly one value for the property schema:description whereas it’s not mandatory for other bbp:Entity instances.\nNote that only the and boolean operator can be used for shape specialization.","title":"Shape specialization"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#frequent-shacl-validation-errors","text":"WIP","title":"Frequent SHACL validation errors"},{"location":"/docs/data-models/neuronclassification/literature.html","text":"","title":"Literature"},{"location":"/docs/data-models/neuronclassification/literature.html#literature","text":"","title":"Literature"},{"location":"/docs/data-models/neuronclassification/literature.html#use-cases","text":"List of use cases: TBD","title":"Use cases"},{"location":"/docs/data-models/neuronclassification/literatureannotation.html","text":"","title":"Literature Annotation"},{"location":"/docs/data-models/neuronclassification/literatureannotation.html#literature-annotation","text":"","title":"Literature Annotation"},{"location":"/docs/data-models/neuronclassification/literatureannotation.html#a-motivating-example","text":"","title":"A motivating example"},{"location":"/docs/data-models/neuronclassification/literatureannotation.html#description","text":"We want to be able to get, from a parameter type, all the data that are in the corpus. From this raw “dump”, we will use NAT for performing the various post-treatments to generate parameter aggregation. Parameter aggregations will need to be registered to Nexus and queried back from Nexus.","title":"Description"},{"location":"/docs/data-models/neuronclassification/literatureannotation.html#competency-questions","text":"Annotation: Get all annotations Get annotations by parameter type (labels ?) Get annotation by id Get annotation by article id (doi,…) Parameter: Get all parameters Get parameters by type Get parameters by annotation id","title":"Competency questions"},{"location":"/docs/data-models/neuronclassification/literatureannotation.html#abstract-data-model","text":"","title":"Abstract Data model"},{"location":"/docs/data-models/neuronclassification/annotation.html","text":"Happy to present @INCForg #Neuroshapes Special Interest Group for #FAIR #neuroscience #data on August 8, 2:30-5:30pm during the @brainhackorg hackathon! We’ll talking about neuroscience data #reusability and #interoperability. Join us https://brainhackmtl.github.io/informatics2018/#schedule","title":"NI2018 #neuroinformagical #semanticweb #shacl"},{"location":"/docs/data-models/neuronclassification/annotation.html#ni2018-neuroinformagical-semanticweb-shacl","text":"","title":"NI2018 #neuroinformagical #semanticweb #shacl"},{"location":"/docs/data-models/neuronclassification/parameter.html","text":"","title":"Parameter"},{"location":"/docs/data-models/neuronclassification/parameter.html#parameter","text":"","title":"Parameter"},{"location":"/docs/data-models/neuronclassification/parameter.html#use-cases","text":"List of use cases: TBD","title":"Use cases"},{"location":"/docs/data-models/neuronclassification/provenance.html","text":"","title":"Provenance"},{"location":"/docs/data-models/neuronclassification/provenance.html#provenance","text":"","title":"Provenance"},{"location":"/docs/data-models/neuronclassification/provenance.html#use-cases","text":"List of use cases: TBD","title":"Use cases"},{"location":"/docs/datamodeling/why-validation.html","text":"","title":"Why Data Validation ?"},{"location":"/docs/datamodeling/why-validation.html#why-data-validation-","text":"","title":"Why Data Validation ?"},{"location":"/docs/datamodeling/why-validation.html#data-validation-as-separate-steps","text":"https://code.tutsplus.com/tutorials/validating-data-with-json-schema-part-1--cms-25343","title":"Data Validation as separate steps"},{"location":"/docs/datamodeling/why-validation.html#why-schemas-","text":"","title":"Why schemas ?"},{"location":"/docs/shacl-tutorial/_convention.html","text":"","title":"Document convention"},{"location":"/docs/shacl-tutorial/_convention.html#document-convention","text":"The @context will be omitted in the following tutorials unless it’s important.","title":"Document convention"},{"location":"/docs/shacl-tutorial/index.html","text":"","title":"SHACL Overview"},{"location":"/docs/shacl-tutorial/index.html#shacl-overview","text":"This document presents an example-driven tutorial on how to build a linked data model for a given domain of application using:\nW3C SHACL recommendation as a data modeling language Blue Brain Nexus as a data management and publishing platform.\nThroughout this document, a simple example of a domain of interest is developed. The example, illustrate different linked data modeling challenges and requirements and demonstrate how they can be met by leveraginb Knowledge about linked data and the Nexus platform REST API is recommended even though not mandatory. You can view the following excellent video on Linked data on youtube.\nNote This tutorial makes use of a SHACL Playground to tests that data conform to schemas. The Nexus explorer will be used to view and navigate the built linked data models.","title":"SHACL Overview"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_validation-flow.html","text":"","title":"What is SHACL ?"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_validation-flow.html#what-is-shacl-","text":"","title":"What is SHACL ?"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_validation-flow.html#shape","text":"How a shape works? SHACL Validation flow\nGiven an input data graph (a json-ld document):\nNode to be focused on for validation are selected using targets: list the different targets Filters can be used to eliminate some focused nodes Validate focused nodes using constraints","title":"Shape"},{"location":"/docs/data-models/neuronclassification/neuronclassification.html","text":"","title":"Literature Annotation"},{"location":"/docs/data-models/neuronclassification/neuronclassification.html#literature-annotation","text":"","title":"Literature Annotation"},{"location":"/docs/data-models/neuronclassification/neuronclassification.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/neuronclassification/neuronclassification.html#description","text":"Axon projection M-type\nSteps: - Get all cell types","title":"Description"},{"location":"/docs/data-models/neuronclassification/neuronclassification.html#competency-questions","text":"","title":"Competency questions"},{"location":"/docs/data-models/neuronclassification/neuronclassification.html#abstract-data-model","text":"","title":"Abstract Data model"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_index.html","text":"","title":"Shacl overview"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_index.html#shacl-overview","text":"","title":"Shacl overview"},{"location":"/docs/shacl-tutorial/overview/overview.html","text":"","title":"SHACL Overview"},{"location":"/docs/shacl-tutorial/overview/overview.html#shacl-overview","text":"","title":"SHACL Overview"},{"location":"/docs/shacl-tutorial/overview/overview.html#shacl-core-components","text":"","title":"SHACL Core Components"},{"location":"/docs/shacl-tutorial/overview/overview.html#a-validation-language-for-a-graph-data-model","text":"","title":"A validation language for a graph data model"},{"location":"/docs/shacl-tutorial/overview/overview.html#basic-definitions","text":"","title":"Basic definitions"},{"location":"/docs/index.html","text":"","title":"Neuroshapes"},{"location":"/docs/index.html#neuroshapes","text":"","title":"Neuroshapes"},{"location":"/docs/index.html#why-neuroshapes-","text":"The goal of Neuroshapes is the development of open, use case driven and shared validatable data models (schemas, vocabularies) to enable the FAIR principles (Findable, Accessible, Interoperable and Reusable) for basic, computational and clinical neuroscience (meta)data. The data models developed thus far entities for electrophysiology, neuron morphology, brain atlases, in vitro electrophysiology and computational modeling. Future developments could include brain imaging, transcriptomic and clinical form data, as determined by community interests.\nNote All data models presented in this documentation are still drafts. Potential changes can be discussed on Github or on Gitter","title":"Why Neuroshapes ?"},{"location":"/docs/index.html#neuroshapes-goals","text":"the use of standard semantic markups and linked data principles as ways to structure metadata and related data: the W3C RDF format is leveraged, specifically its developer-friendly JSON-LD serialization. The adoption of linked data principles and JSON-LD will ease federated access and discoverability of distributed neuroscience (meta)data over the web. the use of the W3C SHACL (Shapes Constraint Language) recommendation as a rich metadata schema language which is formal and expressive; interoperable; machine-readable; and domain-agnostic. With SHACL, (meta)data quality can be enforced based on schemas and vocabularies (easily discoverable and searchable) rather than being fully encoded in procedural codes. SHACL also provides key interoperability capabilities to ensure the evolution of standard data models and data longevity. It allows to incrementally build standard data models in terms of semantics and sophistication. the reuse of existing schemas and semantic markups (like schema.org ) and existing ontologies and controlled vocabularies (including NIFSTD - NIF Standard Ontologies) the use of the W3C PROV-O recommendation as a format to record (meta)data provenance: a SHACL version of the W3C PROV-O is created.","title":"Neuroshapes Goals"},{"location":"/docs/index.html#get-involved","text":"Join the INCF Special Interest Group on Neuroshapes Read the How to contribute section","title":"Get involved"},{"location":"/docs/gettingstarted/index.html","text":"","title":"Getting Started"},{"location":"/docs/gettingstarted/index.html#getting-started","text":"","title":"Getting Started"},{"location":"/docs/gettingstarted/overview.html","text":"","title":"Overview"},{"location":"/docs/gettingstarted/overview.html#overview","text":"A draft for a standardized description of data provenance for the following domains:\nData models Brain Atlas Electrophysiology Morphology\nNote All data models presented in this documentation are still drafts. Potential changes can be discussed on Github or on Gitter","title":"Overview"},{"location":"/docs/gettingstarted/download.html","text":"","title":"Download"},{"location":"/docs/gettingstarted/download.html#download","text":"Neuroshapes schemas are tested using a shacl workbench which is a SBT plugin that helps in the development of SHACL schemas in JSON-LD format. Please follow these steps to run the tests and download the schemas:\nInstall sbt Clone the INCF/neuroshapes repository and run the tests\n# Go to home\ncd ~\n\n# Clone the repository\ngit clone https://github.com/INCF/neuroshapes.git\n\ncd neuroshapes\n\n# Run 'sbt'\nsbt\n\n# Run 'test'\ntest\n\n# Export all the locally defined schemas to the dir /tmp/my-schemas using as base uri \nexportSchemas http://localhost:8080/v0 /tmp/my-schemas\n\n# Schemas can be defined in modules that are imported by local modules. The collectResources command can be run to collect all schemas and contexts defined in this project classpath\n\n## Collect schemas\ncollectResources http://localhost:8080/v1 /tmp/my-schemas schemas\n\n## Collect everything defined\ncollectResources http://localhost:8080/v1 /tmp/my-schemas all","title":"Download"},{"location":"/docs/gettingstarted/contribution.html","text":"","title":"How to contribute"},{"location":"/docs/gettingstarted/contribution.html#how-to-contribute","text":"We would love for you to contribute to the Neuroshapes familly of data models and help make them even better than they are now! As a contributor, find in the next sections the guidelines we would like you to follow.","title":"How to contribute"},{"location":"/docs/gettingstarted/contribution.html#got-a-question-or-a-problem-","text":"Please do not hesitate to open an issue here and join the INCF neuroshapes SIG at INCF Special Interest Group on Neuroshapes.","title":"Got a Question or a Problem?"},{"location":"/docs/gettingstarted/contribution.html#found-a-bug-","text":"If you find a bug in the source code of any tools, in any schema or vocabulary in this repository, you can help us fix it by submitting an issue to our GitHub Repository. Even better, you can submit a Pull Request with a fix.","title":"Found a Bug?"},{"location":"/docs/gettingstarted/contribution.html#missing-a-feature-or-a-data-model-","text":"You can request them by submitting an issue to our GitHub Repository. If you would like to implement a new feature or propose a new data model specification, please submit an issue with a proposal for your work first, to be sure it can be implemented and most importantly, to trigger discussions and enable collaborations with interested people. Please consider what kind of change it is:\nFor a Data Model Specification Proposal or Extension, first open an issue and outline your proposal so that it can be discussed. Data examples implementing/illustrating an existing Data Model can be directly submitted as a Pull Request. For example different atlas releases conformant to the atlas registration prov pattern can be submitted. For a Major Feature related to the tools and scripts made available in this repository, first open an issue and outline your proposal so that it can be discussed. This will also allow us to better coordinate our efforts, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project. Small Features can be crafted and directly submitted as a Pull Request.","title":"Missing a Feature or a data model?"},{"location":"/docs/gettingstarted/contribution.html#submission-guidelines","text":"","title":"Submission Guidelines"},{"location":"/docs/gettingstarted/contribution.html#submitting-an-issue","text":"Before you submit an issue, please search the issue tracker, maybe an issue for your problem already exists and the discussion might inform you of workarounds readily available. We want to fix all the issues as soon as possible, but before fixing a bug we need to reproduce and confirm it. In order to reproduce bugs we will need as much information as possible, and preferably be in touch with you to gather information.","title":"Submitting an Issue"},{"location":"/docs/gettingstarted/contribution.html#submitting-a-data-model-specification","text":"Before you submit your proposal consider the following guidelines:\nPlease join the INCF Special Interest Group (SIG) on Neuroshapes before sending pull requests. Proposals are managed and reviewed by members of that INCF SIG. Open an issue and outline your proposal so that it can be discussed.","title":"Submitting a Data Model Specification"},{"location":"/docs/gettingstarted/contribution.html#submitting-a-pull-request-pr-","text":"Before you submit your Pull Request (PR) consider the following guidelines:\nPlease join the INCF SIG on Neuroshapes before sending Pull requests. Proposals are managed and reviewed by members of that INCF SIG. Clone the Neuroshapes github repository:\n# Go to home\n cd ~\n \n # Clone the repository\n git clone https://github.com/INCF/neuroshapes.git\n \n cd neuroshapes\nMake your changes in a new git branch: shell git checkout -b my-fix-branch master Create your patch, including appropriate test cases. Run the full test suite, and ensure that all tests pass. # Run 'sbt'\nsbt\n\n# Run 'test'\ntest\n\n# Exit\nexit\n\n Commit your changes using a descriptive commit message. shell git commit -a Note: the optional commit -a command line option will automatically “add” and “rm” edited files. Push your branch to GitHub: git push origin my-fix-branch\n In GitHub, send a pull request to the master branch. If we suggest changes then: Make the required updates. Re-run the test suites to ensure tests are still passing. Rebase your branch and force push to your GitHub repository (this will update your Pull Request): git rebase master -i\ngit push -f\n That’s it! Thank you for your contribution! After your pull request is mergedAfter your pull request is merged, you can safely delete your branch and pull the changes from the main (upstream) repository: Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows: git push origin --delete my-fix-branch\n Check out the master branch: git checkout master -f\n Delete the local branch: git branch -D my-fix-branch\n Update your master with the latest upstream version: git pull --ff upstream master","title":"Submitting a Pull Request (PR)"},{"location":"/docs/gettingstarted/contribution.html#join-the-incf-neuroshape-sig","text":"Join the INCF Special Interest Group on Neuroshapes.","title":"Join the INCF Neuroshape SIG"},{"location":"/docs/datamodeling/index.html","text":"","title":"Modeling Your Data"},{"location":"/docs/datamodeling/index.html#modeling-your-data","text":"TBD","title":"Modeling Your Data"},{"location":"/docs/shacl-tutorial/overview/index.html","text":"","title":"SHACL In a Nutshell"},{"location":"/docs/shacl-tutorial/overview/index.html#shacl-in-a-nutshell","text":"Please find below some resources as well as useful links for building data models involving SHACL shapes:\nThe W3C SHACL specification Useful resources when learning SHACL SHACL reference book, tutorials and playground http://www.validatingrdf.com/ SHACL playground: http://shacl.org/playground/ Topquadrant SHACL tutorial Useful resources when learning JSON-LD https://json-ld.org Json-ld API best practicies Ontology/SHACL editor TopBraid Composer Free Edition SHACL validator SHACLEX: scala based pySHACL: python based TopQuadrant/shacl: JAVA based","title":"SHACL In a Nutshell"},{"location":"/docs/data-models/index.html","text":"","title":"Data Model Specifications"},{"location":"/docs/data-models/index.html#data-model-specifications","text":"","title":"Data Model Specifications"},{"location":"/docs/data-models/index.html#overview","text":"This section describes key scientific and technical activities and agents involved in the generation of various neuroscience data types (basic, computational and clinical neuroscience data). For each data types, the generation context is described by mean of a data provenance pattern which is implemented as a set of W3C SHACL based validatable schemas.\nBrain Atlas Electrophysiology Morphology","title":"Overview"},{"location":"/docs/data-models/brainatlas/brain-atlas.html","text":"","title":"Brain Atlas"},{"location":"/docs/data-models/brainatlas/brain-atlas.html#brain-atlas","text":"In this section we describe data models that represent the use of brain atlases.","title":"Brain Atlas"},{"location":"/docs/data-models/brainatlas/brain-atlas.html#use-cases","text":"List of use cases:\nRegistering a brain atlas Registering a whole brain morphology into an atlas","title":"Use cases"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html","text":"","title":"Registering a Brain Atlas"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#registering-a-brain-atlas","text":"","title":"Registering a Brain Atlas"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#description","text":"This specification describes the process of register a brain atlas. The process starts with a subject collection which are imaged and processed to generate 3 derived entities: a template image data, a parcellation image data, as well as brain parcellation labels. The first 2 entities are further transformed into volumetric representation, from which an atlas spatial reference system is derived. The parcellation labels are converted into ontology. The final template volume, parcellation volume, parcellation ontology as well as the atlas spatial reference system are used to form an atlas release.","title":"Description"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#supported-data-queries","text":"From a specific version of a brain atlas:\nGet the brain parcellation dataset Get the brain parcellation labels dataset Get the image stack datasets Get the coordinate system of the atlas spatial reference system","title":"Supported Data Queries"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#data-provenance-pattern","text":"","title":"Data Provenance pattern"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#schemas","text":"","title":"Schemas"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#entities","text":"The different entity types involved are described below.\nType Description SubjectCollection A collection of subject to be used in the experiment TemplateImageData Template image data acquired and processed from the subject collection ParcellationImageData Parcellation image data generated from the template image data ParcellationLabel Parcellation labels correspond to the annotations in the parcellation image TemplateVolume Template volume generated from the template image data ParcellationVolume Parcellation volume generated from the parcellation image data ParcellationOntology Parcellation ontology converted from the parcellation label AtlasSpatialReferenceSystem The spatial coordinate system of the atlas space AtlasRelease An atlas release comprises template volume, parcellation volume, parcellation ontology as well as the atlas spatial reference system Protocol Protocol that describes the method used in the design and execution of the experiment","title":"Entities"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#activities","text":"Type Description Atlas Construction Process to construct a brain atlas Template Reconstruction Reconstruct the template image data into volumetric representation Parcellation Reconstruction Reconstruct the parcellation image data into volumetric representation Ontology Conversion Convert the parcellation label into ontological representation","title":"Activities"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#agents","text":"Type Description Person Person associated with an activity SoftwareAgent Software associated with an activity Organization Organization associated with an activity","title":"Agents"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#contributors","text":"Huanxiang Lu Anna-Kristin Kaufmann Silvia Jimenez Sy Mohameth Francois Samuel Kerrien Sean Hill","title":"Contributors"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html","text":"","title":"Registering a Whole Brain Morphology in an Atlas"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#registering-a-whole-brain-morphology-in-an-atlas","text":"","title":"Registering a Whole Brain Morphology in an Atlas"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#description","text":"This specification describes the process of register a whole brain morphology into an atlas. The process starts with reconstruction the whole brain morphologies from image stack. The image stack is used to register to the reference atlas, resulting in a transformation. This transformation is then used to transform the reconstructed whole brain cell into the reference atlas space.","title":"Description"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#supported-data-queries","text":"Get the whole brain morphology from a given atlas spatial reference system. Get the whole brain morphologies derived from a image stack","title":"Supported Data Queries"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#data-provenance-pattern","text":"","title":"Data Provenance pattern"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#schemas","text":"","title":"Schemas"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#entities","text":"The different entity types involved are described below.\nType Description Subject Subject that was used in the experiment TemplateVolume Template volume generated from the template image data AtlasSpatialReferenceSystem The spatial coordinate system of the atlas space ImageStack Image stack obtained from the brain tissue of the subject ReconstructedCell Reconstructed cell Transform A linear or non-linear transform Protocol Protocol that describes the method used in the design and execution of the experiment","title":"Entities"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#activities","text":"Type Description BrainImaging Technique used to obtain an image stack of the brain tissue containing the cells for reconstruction ReconstructionFromImage Technique used to reconstruct the stained cell Transformation Transform a geometric object","title":"Activities"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#agents","text":"Type Description Person Person associated with an activity SoftwareAgent Software associated with an activity Organization Organization associated with an activity","title":"Agents"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#contributors","text":"Huanxiang Lu Anna-Kristin Kaufmann Silvia Jimenez Sy Mohameth Francois Samuel Kerrien Sean Hill","title":"Contributors"},{"location":"/docs/data-models/electrophysiology/electrophysiology.html","text":"","title":"Electrophysiology"},{"location":"/docs/data-models/electrophysiology/electrophysiology.html#electrophysiology","text":"In Neuroscience, electrophysiology refers to the study of the electrical activity of neurons, e.g. by measuring action potential activity. In this section, we describe data models that represent the generation context of the following neuroscience data types:","title":"Electrophysiology"},{"location":"/docs/data-models/electrophysiology/electrophysiology.html#intracellular-recording","text":"Note In Vitro Whole Cell Patch Clamp Recording In Vitro IntraCellular Sharp Electrode Recording","title":"Intracellular Recording"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html","text":"","title":"In Vitro Whole Cell Patch Clamp Recording"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#in-vitro-whole-cell-patch-clamp-recording","text":"","title":"In Vitro Whole Cell Patch Clamp Recording"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#description","text":"This specification describes the metadata collected for in vitro intracellular electrophysiology recordings using the whole cell patch clamp configuration. Whole cell patch clamp is a type of electrophysiological recording used to measure ionic currents over the membrane of an entire cell. Suction is applied to rupture the cell membrane which provides access to the intracellular space of the patched cell. Metadata is collected on the subject used in the experiment, the slice, the patched cell which was recorded as well as the recording traces and protocols. Additionally, metadata for the brain slicing, the whole cell patch clamp and the stimulus (including protocols and agents) involved in the generation of the recording traces are captured.","title":"Description"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#supported-data-queries","text":"The following points describe an example subset of questions supported by the data provenance pattern:\nRetrieve all recording traces generated from rat somatosensory cortex using selected stimuli. Retrieve recording traces by recording day and experimenter. Retrieve all response traces from a specific patched cell. Get the holding potential for an individual recording trace.","title":"Supported Data Queries"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#data-provenance-pattern","text":"","title":"Data Provenance pattern"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#schemas","text":"","title":"Schemas"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#entities","text":"The different entity types involved in the experiment are listed below.\nType Description Subject Subject that was used in the experiment Slice Brain slice obtained from the subject PatchedSlice Brain slice containing patched cells PatchedCellCollection Collection of patched cells in a single slice (e.g. for multi-patch recordings) PatchedCell Cell that was patched in the slice Trace Individual recording trace of the patched cell (stimulation/input and response/output trace) Protocol Protocol that describes the method used in the design and execution of the experiment","title":"Entities"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#activities","text":"The different activity types involved in the experiment are listed below.\nType Description BrainSlicing Technique used to obtain a brain slice for patching WholeCellPatchClamp Technique used to study electrical activity of individual living cells StimulusExperiment Technique used to obtain the electrical signature of cells through injection of a defined current pattern","title":"Activities"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#agents","text":"The different agent types involved in the experiment are listed below.\nType Description Person Person associated with an activity SoftwareAgent Software associated with an activity Organization Organization associated with an activity","title":"Agents"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#contributors","text":"Anna-Kristin Kaufmann Huanxiang Lu Silvia Jimenez Rodrigo Perin Sy Mohameth Francois Samuel Kerrien Sean Hill","title":"Contributors"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html","text":"","title":"In Vitro IntraCellular Sharp Electrode Recording"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#in-vitro-intracellular-sharp-electrode-recording","text":"","title":"In Vitro IntraCellular Sharp Electrode Recording"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#description","text":"This specification describes the metadata collected for in vitro intracellular electrophysiology recordings using intracellular sharp electrodes configuration. Metadata is collected on the subject used in the experiment, the slice, the cell which was recorded as well as the recording traces and protocols. Additionally, metadata for the brain slicing, the intracellular sharp electrodes and the stimulus (including protocols and agents) involved in the generation of the recording traces are captured.","title":"Description"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#supported-data-queries","text":"The following points describe an example subset of questions supported by the data provenance pattern:\nRetrieve all recording traces generated from rat somatosensory cortex using selected stimuli. Retrieve recording traces by recording day and experimenter. Retrieve all response traces from a specific recorded cell.","title":"Supported Data Queries"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#data-provenance-pattern","text":"","title":"Data Provenance pattern"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#schemas","text":"","title":"Schemas"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#entities","text":"The different entity types involved in the experiment are listed below.\nType Description Subject Subject that was used in the experiment Slice Brain slice obtained from the subject IntraCellularSharpElectrodeRecordedSlice Brain slice containing recorded cells IntraSharpRecordedCellCollection Collection of recorded cells in a single slice IntraCellularSharpElectrodeRecordedCell Cell that was recorded in the slice Trace Individual recording trace of the cell (stimulation/input and response/output trace) Protocol Protocol that describes the method used in the design and execution of the experiment","title":"Entities"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#activities","text":"The different activity types involved in the experiment are listed below.\nType Description BrainSlicing Technique used to obtain a brain slice IntraCellularSharpElectrode Technique used to study electrical activity of individual living cells StimulusExperiment Technique used to obtain the electrical signature of cells through injection of a defined current pattern","title":"Activities"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#agents","text":"The different agent types involved in the experiment are listed below.\nType Description Person Person associated with an activity SoftwareAgent Software associated with an activity Organization Organization associated with an activity","title":"Agents"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#contributors","text":"Andrew Davison Anna-Kristin Kaufmann Huanxiang Lu Silvia Jimenez Sy Mohameth Francois Samuel Kerrien Sean Hill","title":"Contributors"},{"location":"/docs/data-models/morphology/morphology.html","text":"","title":"Neuron Morphology"},{"location":"/docs/data-models/morphology/morphology.html#neuron-morphology","text":"Note In this section we describe data models that represent the generation context of the following neuron morphology data types: In Vitro Slice Neuron Morphology Reconstruction Whole Brain Neuron Morphology Reconstruction","title":"Neuron Morphology"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html","text":"","title":"In Vitro Slice Neuron Morphology Reconstruction"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#in-vitro-slice-neuron-morphology-reconstruction","text":"","title":"In Vitro Slice Neuron Morphology Reconstruction"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#description","text":"This specification describes metadata collected for morphology reconstructions from brain slices. Reconstruction of a neuron morphology from slice typically follows the injection of a dye during a whole cell patch clamp recording. Some of the activities and entities shown here are hence shared with the in vitro whole cell patch clamp recording. Metadata is collected on the subject used in the experiment, the slice containing the cell, the labeled cell and the reconstructed neuron morphology. The dye-filled neuron is most commonly visualized using a histological technique following the fixation of the brain tissue. The stained cells are annotated and then reconstructed. Metadata from all these procedures is captured as well as the protocols used and the persons, software and organizations involved in each of the steps.","title":"Description"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#supported-data-queries","text":"The following points describe an example subset of questions supported by the data provenance pattern:\nRetrieve morphology reconstructions from a given brain region. Retrieve pyramidal cell reconstructions. Retrieve morphology reconstructions from a specific experimenter. Retrieve morphology reconstructions from a subject of a given age and sex. Retrieve morphology reconstructions which were reconstructed in a given year","title":"Supported Data Queries"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#data-provenance-pattern","text":"","title":"Data Provenance pattern"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#schemas","text":"","title":"Schemas"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#entities","text":"The different entity types involved in the experiment are listed below.\nType Description Subject Subject that was used in the experiment Slice Brain slice obtained from the subject PatchedSlice Brain slice containing patched cells PatchedCellCollection Collection of patched cells in a single slice (e.g. for multi-patch recordings) PatchedCell Cell that was patched in the slice FixedStainedSlice Brain slice after fixation and staining AnnotatedSlice Brain slice containing the identified and annotated stained cells LabeledCellCollection Collection of labeled cells in a single slice LabeledCell Cell that was labeled in the slice ReconstructedCell Reconstructed cell Protocol Protocol that describes the method used in the design and execution of the experiment","title":"Entities"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#activities","text":"The different activity types involved in the experiment are listed below.\nType Description BrainSlicing Technique used to obtain a brain slice for patching WholeCellPatchClamp Technique used to study electrical activity of individual living cells FixationStainingMounting Technique used to fix and stain the slice AcquisitionAnnotation Technique used to acquire an image of the slice and annotate the stained cells Reconstruction Technique used to reconstruct the stained cell","title":"Activities"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#agents","text":"The different agent types involved in the experiment are listed below.\nType Description Person Person associated with an activity SoftwareAgent Software associated with an activity Organization Organization associated with an activity","title":"Agents"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#contributors","text":"Anna-Kristin Kaufmann Huanxiang Lu Silvia Jimenez Rodrigo Perin Sy Mohameth Francois Samuel Kerrien Sean Hill","title":"Contributors"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html","text":"","title":"Whole Brain Neuron Morphology Reconstruction"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#whole-brain-neuron-morphology-reconstruction","text":"","title":"Whole Brain Neuron Morphology Reconstruction"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#description","text":"This specification describes metadata collected for whole brain morphology reconstructions from a continuous whole brain image stack. Reconstruction of a neuron morphology from an image stack is typically enabled through sparse neuronal labeling following e.g. viral delivery of a fluorescent protein. Metadata is collected on the subject used in the experiment, the image stack containing the labeled cells and the reconstructed neuron morphology. Additionally, metadata for the brain imaging and the reconstruction from image (including protocols and agents) are captured.","title":"Description"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#supported-data-queries","text":"The following points describe an example subset of questions supported by the data provenance pattern:\nRetrieve morphology reconstructions from a given brain region. Retrieve pyramidal cell reconstructions. Retrieve morphology reconstructions projecting to a given brain region. Retrieve morphology reconstructions from a subject of a given age and sex. Retrieve morphology reconstructions which were reconstructed by a specific person.","title":"Supported Data Queries"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#data-provenance-pattern","text":"","title":"Data Provenance pattern"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#schemas","text":"","title":"Schemas"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#entities","text":"The different entity types involved in the experiment are listed below.\nType Description Subject Subject that was used in the experiment ImageStack Image stack obtained from the brain tissue of the subject ReconstructedCell Reconstructed cell Protocol Protocol that describes the method used in the design and execution of the experiment","title":"Entities"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#activities","text":"The different activity types involved in the experiment are listed below.\nType Description BrainImaging Technique used to obtain an image stack of the brain tissue containing the cells for reconstruction ReconstructionFromImage Technique used to reconstruct the stained cell","title":"Activities"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#agents","text":"The different agent types involved in the experiment are listed below.\nType Description Person Person associated with an activity SoftwareAgent Software associated with an activity Organization Organization associated with an activity","title":"Agents"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#contributors","text":"Anna-Kristin Kaufmann Huanxiang Lu Silvia Jimenez Rodrigo Perin Sy Mohameth Francois Samuel Kerrien Sean Hill","title":"Contributors"},{"location":"/docs/meetings.html","text":"","title":"Meetings and Workshops"},{"location":"/docs/meetings.html#meetings-and-workshops","text":"","title":"Meetings and Workshops"},{"location":"/docs/meetings.html#up-coming-meetings","text":"TBD","title":"Up coming meetings"},{"location":"/docs/meetings.html#past-meetings","text":"","title":"Past meetings"},{"location":"/docs/meetings.html#incf-neuroinformatics-2018-montreal","text":"This meeting was organised 8th of August during the Brainhack hackathon organised the day before the INCF Neuroinformatics 2018 conference. It was the first one for the INCF Neuroshapes Special Interest Group. The goal was mainly to present Neuroshapes motivation to the Neuroscience community at INCF NI2018 but also to connect with other data sharing and open science initiatives like NIDM to see if they can adopt Neuroshapes’ approach in term of data modelling. Participants showed interest in using the W3C SHACL specification, as a way to complement existing data models with data validation capability. They showed interest in the ability to describe what are the expected properties of a dataset by mean of schemas using json-ld (semantic markups) and W3C SHACL.\nNote Read the full meeting report here.","title":"INCF Neuroinformatics 2018, Montreal"},{"location":"/docs/license.html","text":"","title":"License"},{"location":"/docs/license.html#license","text":"Note All Neuroshapes data models and example data are licensed under CC-BY-4.0.","title":"License"},{"location":"/docs/contact.html","text":"","title":"Contact"},{"location":"/docs/contact.html#contact","text":"Note Contact the INCF Special Interest Group on Neuroshapes.","title":"Contact"},{"location":"/docs/releases.html","text":"","title":"Release Notes"},{"location":"/docs/releases.html#release-notes","text":"","title":"Release Notes"},{"location":"/docs/releases.html#neuroshapes-1-0-x","text":"The main goal of Neuroshapes is to provide design patterns, best practices as well as tools to promote:\nThe use of standard semantic markups and linked data principles as ways to structure metadata and related data. The use of the W3C SHACL (Shapes Constraint Language) recommendation as a rich metadata schema language which is formal and expressive; interoperable; machine-readable; and domain-agnostic. The reuse of existing schemas and semantic markups ( schema.org , W3C PROV-O ) and existing ontologies and controlled vocabularies (including NIFSTD - Neuroscience Information Framework Standard Ontologies). The use of the W3C PROV-O recommendation as a format to record (meta)data provenance.\nIn Neuroshapes, many neuroscience data types are specified based on the key scientific and technical activities and agents that lead to their generation. The specifications are defined in validatable provenance-based data models and implemented using open and interoperable semantic web technologies.\nNeuroshapes has been used in production within various organisations for more than a year.\nFind below the notable changes from the previous release.","title":"Neuroshapes 1.0.x"},{"location":"/docs/releases.html#vocabulary-taxonomy-and-ontology-changes","text":"Neuroshapes main approach has been to build on top of existing initiatives for common (http://schema.org) and provenance (https://www.w3.org/TR/prov-o/) vocabularies. The v1.0.x release includes major alignment in terms of vocabularies with a systematic map to schema.org and W3C PROV-O if relevant and available:\nnsg:datePublished => schema:datePublished dcterms:hasPart => schema:hasPart nsg:hasPart => schema:hasPart dcterms:isPartOf => schema:isPartOf dcat:Distribution => schema:DataDownload nsg:endedAtTime => prov:endedAtTime nsg:startedAtTime => prov:startedAtTime schema:mediaType => schema:encodingFormat dcat:downloadURL => schema:contentUrl dcat:accessURL => schema:url nxv:digest => nsg:digest nsg:Entity => prov:Entity nsg:Activity => prov:Activity nsg:SoftwareAgent => prov:SoftwareAgent nsg:Organization => schema:Organization nsg:Person => schema:Person nsg:Collection => prov:Collection nsg:Collection => nsg:SubjectCollection nsg:Collection => prov:Collection nsg:EmptyCollection => prov:EmptyCollection\nThe above mapping brings unicity in term of types (e.g. no more nsg:Activity and prov:Activity).\nTwo new namespaces are introduced:\nhttps://neuroshapes.org/ with nsg as prefix: for all neuroscience specific types, properties and shapes. https://provshapes.org/ with prov as prefix: for all W3C PROV-0 provenance related types, properties and shapes.\nA core ontology is now introduced. It contains a set of types along with their definitions. The neurosciencegraph core data and schema contexts are also removed to avoid having users to manage them with multiple versions. Instead, the two contexts will only be generated upon Neuroshapes release:\ndata context: this context is identified by and accessible at https://incf.github.io/neuroshapes/contexts/data.json schema context: this context is identified by and accessible at https://incf.github.io/neuroshapes/contexts/schema.json\nThis release represents a commitment to backwards compatibility for contexts, vocabulary and ontologies in all future releases.","title":"Vocabulary, taxonomy and ontology changes"},{"location":"/docs/releases.html#shapes-changes","text":"Added:\ncontribution, license and language shapes taxonomy and ontology shapes boundingbox shape distribution shape BrainLocation shape\nRemoved:\nmediatype schema https://neuroshapes.org/dash/agent schema https://provshapes.org/dash/activity schema https://provshapes.org/dash/person https://provshapes.org/dash/organization https://neuroshapes.org/dash/entity schema https://provshapes.org/dash/collection Reused usage shape in activity shape\nConstraints:\nWholeCellPatchClamp activity now used nsg:SliceCollection instead of nsg:Slice WholeCellPatchClamp activity now is not required to have one generated entity","title":"Shapes changes"},{"location":"/docs/releases.html#technical-and-repository-structure-changes","text":"Previously, Neuroshapes’ github repository was made of multiple scala modules with one module for each neuroscience domain: Neuron Morphology, Brain Atlas, Ephys recording,… A set of shapes representing neuroscience entities were defined in each module. The Neuroshapes scala modules themselves imported provenance shapes from BlueBrain/nexus-prov and some BlueBrain Nexus built-in shapes. This structure was complex and was not easy to understand and relate with the main goals of Neuroshapes.\nThe v1.0.x release comes with a single scala module and a new simplified Github structure clearly showing:\nthe recommended taxonomies: in taxonomies dir the recommended ontologies: in ontologies dir the defined shapes for provenance description and for neuroscience entities and data types: in shapes dir. The shapes dir contains two categories of shapes: ** the provenance ones in shapes/prov: which are now located in the Neuroshapes Github repository instead of being inherited from BlueBrain/nexus-prov. ** the neuroscience ones: in shapes/neurosciencegraph\nShapes are now grouped in two categories:\ncommon shapes: these are libraries of useful shapes built mainly for reuse (e.g. QuantitativeValue). They often don’t define a target thus preventing them from being used alone to validate data. The related namespaces are:\n** https://neuroshapes.org/commons/ ** https://provshapes.org/commons/\ndata shapes (https://neuroshapes.org/dash/): these shapes to be used to validate actual data. They often make use of common shapes and define a target. The related namespaces are:\n** https://neuroshapes.org/dash/ ** https://provshapes.org/dash/","title":"Technical and Repository structure changes"},{"location":"/docs/shacl-tutorial/index-old.html","text":"","title":"SHACL vs OWL ?"},{"location":"/docs/shacl-tutorial/index-old.html#shacl-vs-owl-","text":"To understand the difference between SHACL and OWL inference for example let consider the following example:\nowl: for an instanve to be a person, it has to have a name => necessary and/or sufficient defining conditions useful for classification SHACL: if you are a person then you should have a name => mandatory or optional conditions to meet expectations","title":"SHACL vs OWL ?"},{"location":"/docs/shacl-tutorial/index-old.html#introduction-to-shacl","text":"This document presents an example-driven tutorial on how to build a linked data model for a given domain of application using:\nW3C SHACL recommendation as a data modeling language Blue Brain Nexus as a data management and publishing platform.\nThroughout this document, a simple example of a domain of interest is developed. The example, illustrate different linked data modeling challenges and requirements and demonstrate how they can be met by leveraginb Knowledge about linked data and the Nexus platform REST API is recommended even though not mandatory. You can view the following excellent video on Linked data on youtube.\nNote This tutorial makes use of a SHACL Playground to tests that data conform to schemas. The Nexus explorer will be used to view and navigate the built linked data models.\nThe tutorial is organised as follows:\nA presentation of the data examples that will be used throughout this tutorial","title":"Introduction to SHACL"},{"location":"/docs/shacl-tutorial/getting-started.html","text":"","title":"Getting Started in 5 mn"},{"location":"/docs/shacl-tutorial/getting-started.html#getting-started-in-5-mn","text":"","title":"Getting Started in 5 mn"},{"location":"/docs/shacl-tutorial/getting-started.html#install-the-nexus-cli","text":"pip install nexus-cli","title":"Install the Nexus CLI"},{"location":"/docs/shacl-tutorial/getting-started.html#create-a-new-working-space-in-nexus-sandbox","text":"nexus init","title":"Create a new working space in Nexus sandbox"},{"location":"/docs/shacl-tutorial/getting-started.html#set-acls","text":"nexus init","title":"Set acls"},{"location":"/docs/shacl-tutorial/getting-started.html#define-a-data-model","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/Circuit_1_2\",\n \"@type\" : \"sh:NodeShape\",\n \"targetNode\" : [\"bbp:Circuit_1\",\"bbp:Circuit_2\"]\n } ]\n}","title":"Define a data model"},{"location":"/docs/shacl-tutorial/getting-started.html#push-data","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/Circuit_1_2\",\n \"@type\" : \"sh:NodeShape\",\n \"targetNode\" : [\"bbp:Circuit_1\",\"bbp:Circuit_2\"]\n } ]\n}","title":"Push data"},{"location":"/docs/shacl-tutorial/getting-started.html#query-your-data","text":"
    \n \t\t\t
    typed.js — bash — 80x10
    \n \t\t\t
    \n \t\t\t\t$ Try it out!|\n \t\t\t
    \n \t\t
    ","title":"Query your data"},{"location":"/docs/shacl-tutorial/getting-started.html#data-examples","text":"","title":"Data examples"},{"location":"/docs/shacl-tutorial/tutorial-example/index.html","text":"","title":"A little Academic Publishing Domain"},{"location":"/docs/shacl-tutorial/tutorial-example/index.html#a-little-academic-publishing-domain","text":"For the purpose of this tutorial let consider a scientific publisher that wants to build an application to manage publication data. Let call this application domain an academic publishing domain within which there is a researcher named Anna whom activities need to be modeled and queried. Anna works at the NEXT-AI laboratory of the NEXT-School, a world renowned research institution. She is specialized in Artificial intelligence, a research area for which she is one of the top contributors as she published many scientific articles in top AI journals as well as many AI related books. She is recipiendaire of many international grants from public research funding agencies like EU ERC grant that she won in collaboration with other researchers.","title":"A little Academic Publishing Domain"},{"location":"/docs/shacl-tutorial/tutorial-example/index.html#knowledge-graph-perspective","text":"Let adopt a knowledge graph perspective to illustrate this domain entities and relations:","title":"knowledge graph perspective"},{"location":"/docs/shacl-tutorial/tutorial-example/index.html#the-domain-competency-questions","text":"The produced data model should support the following queries: that is to say the model competency questions:\nGet the researcher’s metadata (e.g. famillyName, givenName, email) Get the researcher’s area of studies (e.g. famillyName, givenName, email) Get the researcher’s affiliations Get the researcher’s publications Get the researcher’s current and past grants What are the researchers that co-author a scientific article with Anna ?","title":"The domain competency questions"},{"location":"/docs/shacl-tutorial/tutorial-example/index.html#the-domain-entities","text":"To answer the above questions, the following entities need to be considered:\nResearcher Researchers’ affiliations which are organisations Research Grant Scientific Publication\nEach of the above entities needs to be described using a given set of properties.\nAll of the above entities can be described using metadata from schema.org. A Researcher can be described with the following set of metadata:\nProperty Description name The researcher name given name Brain slice obtained from the specimen affiliations Brain slice with patched cells PatchedCellCollection Collection of patched cells in a single slice PatchedCell Cell that was patched in the slice Trace Individual recording trace of the patched cell (StimulationTrace and ResponseTrace) Protocol Document that describes the method used in the design and implementation of an experiment\nHopefully To help answer the above questions, the following datasets will be used:\nSource:\norcid springer nature","title":"The domain entities"},{"location":"/docs/shacl-tutorial/tutorial-example/start-simple.html","text":"","title":"Start simple"},{"location":"/docs/shacl-tutorial/tutorial-example/start-simple.html#start-simple","text":"Let start out with very simple descriptions of the entities in the little publishing domain.","title":"Start simple"},{"location":"/docs/shacl-tutorial/tutorial-example/start-simple.html#researcher-description","text":"A Researcher can be described by a givenName, a familyName as well as its affiliations.\n{\n \"@context\":\"http://schema.org\",\n \"@type\" : \"Person\",\n \"giveName\" : \"Alice\",\n \"familyName\" : \"Alice\",\n \"affiliations\":[]\n}\nProperty Description familyName The researcher family name givenName The researcher given name affiliations The institutions (labs, universities,…) the researcher is affiliated to identifier The researcher persistent digital identifier orcid identifiers","title":"Researcher description"},{"location":"/docs/shacl-tutorial/tutorial-example/start-simple.html#organization-description","text":"Hopefully To help answer the above questions, the following datasets will be used:","title":"Organization description"},{"location":"/docs/shacl-tutorial/tutorial-example/start-simple.html#grant-description","text":"","title":"Grant description"},{"location":"/docs/shacl-tutorial/tutorial-example/start-simple.html#scientific-publication-description","text":"","title":"Scientific Publication description"},{"location":"/docs/shacl-tutorial/overview/data-modeling-approach.html","text":"","title":"Data modeling approach"},{"location":"/docs/shacl-tutorial/overview/data-modeling-approach.html#data-modeling-approach","text":"Shapes are different from types closed shapes: anyone can say anything about anything least power","title":"Data modeling approach"},{"location":"/docs/datamodeling/linkeddata/rdf/index.html","text":"","title":"JSON for Linking Data"},{"location":"/docs/datamodeling/linkeddata/rdf/index.html#json-for-linking-data","text":"Note This section introduces basic concepts of JSON for Linked Data (JSON-LD). The reader should look at the JSON-LD specification for in-depth documentation.\nJSON-LD is a very flexible format allowing multiple json representation for the same content as shown in the following example:","title":"JSON for Linking Data"},{"location":"/docs/datamodeling/linkeddata/rdf/index.html#why-json-ld-","text":"First of all a json-ld document is a json document. So what is the difference ? To help answer the question, let consider the following json document:\n{\n \"identifier\" : \"0e3b328c-c18f-4e64-9a0e-f6e4f32b36da\",\n \"python\":\"fast\",\n \"java\" : \"\"\n}\nWhat this document is about ? Python and Java as programming languages or as snake and the indonesia island respectively ? The json document is ambiguous. With just the payload, human and software agents can’t confidently infer the document topic without knowing from which endpoint it was obtained.\nsemantic preserving data exchange\nJson-ld specification was created to solve the above ambiguity issue among other features it brings to the way web resources are exchanged through API. To enable semantic preserving data exchange, it adds a context object to the json document within which each json keys and/or values can be mapped to a unique identifier as shown in the following document:\n{\n \"@context\":{\n \"python\":\"http://programminglanguages.org/python\",\n \"java\":\"http://programminglanguages.org/java\",\n \"identifier\":\"@id\"\n },\n \"identifier\" : \"0e3b328c-c18f-4e64-9a0e-f6e4f32b36da\",\n \"python\":\"fast\",\n \"java\" : \"\"\n}\nA JSON-LD context is simply a mapping:\nfrom a key often called prefix and sometimes aliases: python, java as well as identifier are prefixes to a value often called namespace: *http://programminglanguages.org/python* is a namespace\nNote The JSON-LD document can be seen within the json-ld playground.\nWhen written with a context object, a JSON-LD document is said to be compacted. On the opposite, the json-ld context is said expanded when its context is applied, i.e all prefixes as well as aliases are replaced by their corresponding namespaces. Find below the expanded form of the json-ld document example above:\n{\n \"@id\" : \"0e3b328c-c18f-4e64-9a0e-f6e4f32b36da\",\n \"http://programminglanguages.org/python\":\"fast\",\n \"http://programminglanguages.org/java\" : \"\"\n}","title":"Why JSON-LD ?"},{"location":"/docs/datamodeling/linkeddata/rdf/index.html#json-ld-data-model","text":"A JSON-LD document can be seen a json tree or as a RDF document (Resource description Framework).\nNote The reader can checkout the full RDF recommendation here.\nAs one of the multiple RDF document serialization format, a JSON-LD document can be seen as a directed graph where every of piece of knowledge about a thing always comes in three and is broken down in (**subject, predicate, object**):\n(subject, predicate, object) is often called a statement, an assertion, a fact or more technically a triple just like in most programming languages (python, java,…). So a JSON-LD document can be seen as a collection of triples.\nThe graph vocabulary is often used when naming elements of a triple:\nthe subject and the object are called nodes while the predicate is called property or arc\nHere is the set of triples corresponding to the json-ld document above:\n…","title":"JSON-LD data model"},{"location":"/docs/datamodeling/linkeddata/rdf/index.html#cool-uris-dont-change","text":"Elements of a JSON-LD document have URIs as identifiers. For example, the URI of the Allen human brain atlas ontology (as integrated in NIP) is http://api.brainmap.org/api/v2/data/Structure, while the URI of the specific term “gray matter” is http://api.brainmap. org/api/v2/data/Structure/4006 . The previous two URIs can have a short form which is called prefix (a stable string) for the ontology and CURIE for the ontology entities. Let take again the previous example. The prefix name of (the short form of) “ http://api.brainmap. org/api/v2/data/Structure ” can be ‘HBA’ while the curie of the term ’’grey matter\" is ‘HBA:4006’. Given the curie ‘HBA:4006’, ‘HBA’ is the prefix name and ‘4006’ is the fragment.","title":"Cool URIs don’t change"},{"location":"/docs/datamodeling/linkeddata/rdf/index.html#further-reading","text":"JSON-LD Best Practices\nJSON-LD","title":"Further reading"},{"location":"/docs/datamodeling/linkeddata/rdf/uris.html","text":"","title":"Cool URIs dont change"},{"location":"/docs/datamodeling/linkeddata/rdf/uris.html#cool-uris-dont-change","text":"","title":"Cool URIs don’t change"},{"location":"/docs/datamodeling/linkeddata/rdf/json-ld.html","text":"","title":"JSON-LD"},{"location":"/docs/datamodeling/linkeddata/rdf/json-ld.html#json-ld","text":"SHACL is for validating data represented using the Resource Description Framework (RDF). So, before starting to describe SHACL in details, it is important to introduce some concepts of RDF. The goal of this section is not to fully describe RDF data model but rather introduce some of its core concepts that are necessary to understand SHACL.","title":"JSON-LD"},{"location":"/docs/datamodeling/linkeddata/rdf/readings.html","text":"","title":"Further Reading"},{"location":"/docs/datamodeling/linkeddata/rdf/readings.html#further-reading","text":"","title":"Further Reading"},{"location":"/docs/data-models/minds/schemas.html","text":"","title":"Schemas"},{"location":"/docs/data-models/minds/schemas.html#schemas","text":"List of use cases: TBD","title":"Schemas"},{"location":"/docs/shacl-tutorial/tutorial-example/researcher.html","text":"","title":"A little Academic Publishing Domain"},{"location":"/docs/shacl-tutorial/tutorial-example/researcher.html#a-little-academic-publishing-domain","text":"The produced domain model should support the following queries: that is to say the competency questions.\nGet the researcher’s description Get the researcher’s area of studies Get the researcher’s affiliations Get the researcher’s publications Get the researcher’s current and past grants\nTo answer the above questions, the following entities need to be considered:\nResearcher Researchers’ affiliations which are organisations Research Grant Scientific Publication\nLet adopt a knowledge graph perspective to illustrate this domain:\nEach of the above entities needs to be described using a given set of properties.\nAll of the above entities can be described using metadata from schema.org. A Researcher can be described with the following set of metadata:\nProperty Description name The researcher name given name Brain slice obtained from the specimen affiliations Brain slice with patched cells PatchedCellCollection Collection of patched cells in a single slice PatchedCell Cell that was patched in the slice Trace Individual recording trace of the patched cell (StimulationTrace and ResponseTrace) Protocol Document that describes the method used in the design and implementation of an experiment\nHopefully To help answer the above questions, the following datasets will be used:\nSource:\norcid springer nature","title":"A little Academic Publishing Domain"},{"location":"/docs/data-models/minds/vocabulary.html","text":"","title":"Vocabulary"},{"location":"/docs/data-models/minds/vocabulary.html#vocabulary","text":"","title":"Vocabulary"},{"location":"/docs/data-models/minds/vocabulary.html#namespaces","text":"List of use cases: TBD","title":"Namespaces"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_index.html","text":"","title":"Nexus Schema Best Practices"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_index.html#nexus-schema-best-practices","text":"","title":"Nexus Schema Best Practices"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html","text":"","title":"Node shapes identifiers"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#node-shapes-identifiers","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/CircuitShape\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"property\":[{\n \"@id\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/ConnectomeShape\",\n \"path\": \"bbpprodprop:connectome\"\n \"name\": \"Connectome\",\n \"description\": \"Connectome\",\n \"datatype\": \"xsd:string\",\n \"maxCount\": 1,\n \"minCount\": 0\n }\n ]\n }\n ]\n}\nIt is strongly recommended to provide identifiers (value for @id) for the node shapes (things of type sh:NodeShape) so that they can be reused and discovered through the Nexus Rest API.\nBoth node shapes and property shapes can have identifiers.\nA property shape needs to have an identifier only if there is a need to reuse it.","title":"Node shapes identifiers"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#nexus-schema-annotations","text":"Schemas are often designed with reuse in mind. Good annotations is key in order to enable schema discoverability and reuse. The following list presents a set of recommended annotations that one can use to describe a schema:\n…WIP","title":"Nexus schema annotations"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#shape-annotations","text":"","title":"SHAPE annotations"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#node-shape-annotations","text":"Node shapes are shapes with type sh:NodeShape. It is recommended that a node shape is annotated with the following properties:\nKey Description label A human readable label for the node shape. This property is a short form for rdfs:label. comment A human readable description of the node shape.This property is a short form for rdfs:comment.","title":"Node shape annotations"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#property-shape-annotations","text":"Property shapes are shapes with type sh:PropertyShape. It is recommended that a property shape is annotated with the following properties:\nKey Description name A human readable name for the shape. The name is usually displayed when a form is generated from the shape description A human readable description of the shape. Also used in form generation\nAnnotation properties are not taken into accoiunt during validation.","title":"Property shape annotations"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#shape-keys-ordering","text":"To improve the SHACL schema readability, it is recommended to adopt the following ordering when defining:\na Node Shape\nOrder Key Description 1 @id Always start with the node shape identifier if any 2 @type The node shape type 3 label A human readable description of the node shape. 4 comment A description of the node shape. 5 target(Class-Node-ObjectsOf-SubjectsOf) The node shape target 6 nodeKind The node shape node kind 7 property The node shape properties\na Property Shape\nOrder Key Description 1 @id Always start with the property shape identifier if any. Most of the time, there is no need to have an identifier for a property shape 2 @type The property shape type. Most of the time, there is no need to add a type to a property shape 3 path The property targeted by the property shape. 4 name A human readable name for the property shape. 5 description A human readable description of the property shape. 6 nodeKind The property shape node kind. Cannot be present when datatype is present. 7 class or datatype These two keys are mutually exclusive. THus they can occurs in the same property shape at the same time. Every value of the targeted property (defined in path) should have the value of class or datatype as type 8 node Always has a node shape as value. Every value of the targeted property (defined in path) should conform to the referenced node shape. 9 minCount or maxCount Cardinality constraints.","title":"SHAPE keys ordering"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#naming-conventions","text":"","title":"Naming conventions"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#class-name-as-single-noun","text":"In schemas, classes (values of targetClass, of @type) are named using camel case notation:\nclass name should start with a capital letter class name should be singular no space is allowed good examples: “bbp:Circuit”, bbp:RawMorphology bad examples: “bbp:Circuits”, “bbp:circuit” but also “bbp:Raw_Morphology”","title":"Class name as single noun"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#instance-name-as-single-noun","text":"Instances naming follows the same conventions as class naming. In a schemas, instances are things that have a type (@type): mainly the shapes (node and property shapes).","title":"Instance name as single noun"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#property-name-as-verb-sense-or-single-noun","text":"In schemas, properties (mainly values of sh:path) are named using the following convention:\nproperty name should start with lower case and be capitalized thereafter property name should be singular no space is allowed good example: “bbp:morphology”, “bbp:hasFileExtension” or “bbp:fileExtension” bad examples: “bbp:morphologies” but also “bbp:segment_index”","title":"Property name as verb sense or single noun"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html","text":"","title":"Brain Atlas Derivation"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html#brain-atlas-derivation","text":"","title":"Brain Atlas Derivation"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html#description","text":"TBD","title":"Description"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html#competency-questions","text":"TBD","title":"Competency questions"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html#provenance-pattern","text":"Link towards the provenance pattern: TBD","title":"Provenance pattern"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html#entities","text":"The different entity types involved are described below.\nType Description An Entity type A description","title":"Entities"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html#activities","text":"Type Description An activity Type A description","title":"Activities"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html#agents","text":"Type Description An Agent Types A description","title":"Agents"},{"location":"/docs/shacl-tutorial/how-to/_index.html","text":"","title":"How to"},{"location":"/docs/shacl-tutorial/how-to/_index.html#how-to","text":"","title":"How to"},{"location":"/docs/shacl-tutorial/overview/constraints.html","text":"","title":"Constraints"},{"location":"/docs/shacl-tutorial/overview/constraints.html#constraints","text":"Co-occurrence constraints\nA shape can defined a set of constraints to be checked against selected nodes. The set of possible constraints can be divided into two categories:\nNodeKind constraint: about selected nodes themselves Property constraints: about outgoing or incoming properties of each selected node","title":"Constraints"},{"location":"/docs/shacl-tutorial/overview/constraints.html#nodekind-constraint","text":"The nodeKind constraint allows to choose if a selected need to be identified by an IRI eventually consistent with a specific pattern or if it can unidentified. At most one nodeKind constraint can be defined for a given NodeShape.\nThe following schema states that all values of the property bbp:morphology have to be nodes identified by IRIs.\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertyObject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetObjectsOf\" : \"bbp:morphology\",\n \"nodeKind\": \"sh:IRI\"\n } ]\n}\nIn the previous example, the node “Morphology_1” (red border) is an object of the property bbp:morphology which is a Literal (precisely a string literal). So it’s not identifier by an IRI which makes it invalid. The node bbp:Morphology_2 (green border) on the other hand is valid because it is an object property of the property bbp:morphology and is identified by an IRI. All values of the nodeKind constraint are listed in the table below:\nValue Description sh:IRI The selected nodes have to be identified by a valid IRI. sh:BlankNode The selected nodes should not be identified by an IRI nor be a Literal. sh:Literal The selected nodes should be a Literal. sh:BlankNodeOrIRI Disjunctive combination of sh:BlankNode and sh:IRI. sh:BlankNodeOrLiteral Disjunctive combination of sh:BlankNode and sh:Literal. sh:IRIOrLiteral Disjunctive combination of sh:IRI and sh:Literal.","title":"NodeKind Constraint"},{"location":"/docs/shacl-tutorial/overview/constraints.html#property-constraints","text":"Definition of bbp:morphology as an outgoing property of any instance of bbp:Circuit:\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\"\n }\n } ]\n ]\n}\nGiven a selected node, a shape defines a set of outgoing and/or incoming properties as well as a set of constraints for each of them. By doing so, a shape enforce a vocabulary (a set of properties) to be used for describing the selected nodes (instances of bbp:Circuit in the schema for example) and how that vocabulary should be used (constraints).\nTo define a set of incoming and/or outgoing properties, the property key is used. It is an array and each of its item is an instance of a PropertyShape. The following tables describe the minimal keys to use in order to define a property:\nkey Description path MAandatory. Refers to the property IRI (“bbp:morphology” in the schema example) in case of outgoing property. For an incoming one, the following syntax is used: “path” : [ “sh:inversePath prov:generated” ]. name Optional. A human readable name of the property. The name can be used in generated forms for example. description Optional. Description of the property.\nOnce the property shape is defined, a set of constraints can be attached to it.\nCardinality Constraints\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:dataSpace\",\n \"name\" : \"Data Space\",\n \"description\" : \"Data Space.\",\n \"minCount\":\"1\"\n }\n ]\n }\n ]\n}\nHow many outgoing “bbp:morphology” properties a specific bbp:Circuit instance can have ? A question that can be reformulated as: how many triples following the pattern (bbp:Circuit_*, bbp:morphology, object) can exist in the data graph ? The answers can be: zero or more, exactly one, at most one. To enforce one of these answers a cardinality constraint can be defined and attached to a property shape as shown in the schema example. The default value for minCount and maxCount is 0.\nThe example schema states that all instances of bbp:Circuit should have at least one value for bbp:morphology property and at most 3 values. They should have at least one value for bbp:dataSpace property as well. In the example data graph below, bbp:Circuit_1 is valid because it has one value for bbp:morphology property and one value for bbp:dataSpace. On the other hand, bbp:Circuit_2 is not valid because it has not a value for bbp:dataSpace property.\nProperty Value Type Constraints\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:dataSpace\",\n \"name\" : \"Data Space\",\n \"description\" : \"Data Space.\",\n \"minCount\":\"1\"\n },\n {\n \"path\" : \"bbp:brainRegion\",\n \"name\" : \"Brain region\",\n \"description\" : \"Brain region.\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\",\n \"node\": \"circuitshape:LabeledOntologyTermShape\"\n },\n {\n \"path\" : \"schema:name\",\n \"name\" : \"Name\",\n \"description\" : \"Circuit name\",\n \"datatype\": \"xsd:string\",\n \"minCount\":\"1\",\n \"maxCount\":\"1\"\n }\n ]\n },\n {\n \"@id\" : \"circuitshape:LabeledOntologyTermShape\",\n \"@type\" : \"sh:NodeShape\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"rdfs:label\",\n \"name\" : \"label\",\n \"description\" : \"Human readable label\",\n \"datatype\": \"xsd:string\",\n \"maxCount\" : 1,\n \"minCount\" : 1\n\n }\n }\n ]\n}\nThe type of a property value can be restricted. In the schema example, all instances of bbp:circuit should have exactly one name which should be of type string. How to express such type restriction in a shacl schema ?\nPrimitive type as property value\nA property value can be of a primitive type: string, integer, double, anyURI, … and datatype key is used to define such primitive expected types as shown in the shacl schema example. The namespace of all primitive types is xsd and for a complete list of those types please check here.\nProperty values are not always primitive and two other typical situations may occurs.\nReference as property value\nThe type of a property value can be restricted to be an instance of a specific class. For example, it may be useful to enforce all values of the bbp:morphology property of a given circuit to be of type bbp:Morphology. To express this type of constraint the key class is used as shown in the schema example. The ability to constraint types is important to ensure the quality and reliability of the data being submitted into the Nexus platform and SHACL allows to do that without writing a single line of validation code.\nNode as property value\nSometimes it may be useful to enforce that a property value has a particular shape instead of being of a specific type. For example, we may want to enforce all brain region values of a all circuits (instances of bbp:Circuit) to have at least an IRI as identifier (“nodeKind”: “sh:IRI”) and a label as human readable description. The key node is used to express a shape constraint.","title":"Property Constraints"},{"location":"/docs/shacl-tutorial/overview/constraints.html#qualified-cardinality","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"3\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:morphology\",\n \"qualifiedValueShape\": {\n \"class\" : \"bbp:RawMorphology\"\n },\n \"qualifiedValueShapesDisjoint\": true,\n \"qualifiedMinCount\":1,\n \"qualifiedMaxCount\":1\n },\n {\n \"path\" : \"bbp:morphology\",\n \"qualifiedValueShape\": {\n \"class\" : \"bbp:SynthesizedMorphology\"\n },\n \"qualifiedValueShapesDisjoint\": true,\n \"qualifiedMinCount\":1\n }\n ]\n }\n ]\n}\nCardinality constraints can be more complex than what is presented in the constraints section above. A complex cardinality use case can be expressed in the following way : *a bbp:Circuit instance should be linked with exactly 3 Morphologies (instances of bbp:Morphology) *exactly one of them should be a raw morphology (an instance of bbp:RawMorphology) *at least one of them should be synthesized morphology (an instance of bbp:SynthesizedMorphology) *and a bbp:Circuit instance can’t be at the same time of type bbp:RawMorphology and bbp:SynthesizedMorphology\nThe schema example shows how to implement the above constraints using the following keys:\nkey Description qualifiedValueShape Mandatory. The shape that the specified (through qualifiedMinCount and qualifiedMaxCount) number of nodes should be consistent with. qualifiedMinCount Mandatory. The minimum number of nodes that should be consistent with the shape in qualifiedValueShape qualifiedMaxCount Mandatory. The maximum number of nodes that should be consistent with the shape in qualifiedValueShape qualifiedValueShapesDisjoint Optional. If true then the values conform to the current property shape must not conform to the siblings property shapes","title":"Qualified Cardinality"},{"location":"/docs/shacl-tutorial/overview/constraints.html#combining-shapes","text":"Until now we’ve described how to define a shape that targets different nodes using different selectors and enforcing different type of constraints. But designing real life schemas is complex and often required reuse of already defined ones. Two use cases can occur when it comes to reuse SHACL schemas:\nreuse a shape by combining it with other shapes using boolean operators specialization mechanism between shapes","title":"Combining shapes"},{"location":"/docs/shacl-tutorial/overview/constraints.html#logical-combination-of-shapes","text":"A node shape definition for all instances of bbp:Entity\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"this:EntityShape\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Entity\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [{\n \"path\" : \"schema:name\",\n \"name\" : \"Name\",\n \"description\" : \"Entity name\",\n \"or\":[\n {\n \"datatype\": \"xsd:string\"\n },\n {\n \"datatype\": \"xsd:integer\"\n }\n ]\n },{\n \"path\" : \"schema:description\",\n \"name\" : \"Description\",\n \"description\" : \"The entity description\",\n \"datatype\" : \"xsd:string\"\n }\n ]\n }\n ]\n}\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"@type\": \"owl:Ontology\",\n \"imports\" : [ \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\"],\n \"shapes\" : [ {\n \"@id\" : \"this:Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"and\":[{\n \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\"\n },\n {\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n }\n ]\n }\n ]\n }\n ]\n}\nShapes can be combined using the following boolean operators:\nkey Description and The data has to be valid with respect to all combined shapes or The data has to be valid with respect to at least one shape xone The data has to be valid with respect to only one shape not The data should not be valid with respect to the given shape(s)\nIn the previous schema (identified by {endpoint}/schemas/bbp/simulation/circuit/v1.0.0/), the property shape related to schema:name property can be externalized in a schema ({endpoint}/schemas/bbp/core/entity/v1.0.0/) belonging to the “bbp” organization, “core” domain and named “entity” as shown in the right tab. Now let reuse (see in the right) the entity schema since a bbp:Circuit is a bbp:Entity as well. Basically, the schema is expressing that a bbp:Circuit instance should be consistent with respect to the schema for bbp:Entity (external one) and the one for bbp:Circuit (local one).\nNote the use of the **imports** key. It tells the shacl validator where to find the shapes that are referenced in the local schema: \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\" for example. Only published schemas can be imported.\nThe or, xone and not operators can be used in the same way as the and one. The example shows how to logically combined two node shapes. Property shapes can be combined as well as shown in the shape this:EntityShape where the property schema:name van be of type string of integer.\nAll shapes that are listed in the shapes array are by default considered combined in conjunctive way (and operator).","title":"Logical combination of shapes"},{"location":"/docs/shacl-tutorial/overview/constraints.html#shape-specialization","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"@type\": \"owl:Ontology\",\n \"imports\" : [ \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\"],\n \"shapes\" : [ {\n \"@id\" : \"this:Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"and\":[{\n \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\"\n },\n {\n \"property\" : [\n {\n \"path\" : \"schema:description\",\n \"minCount\" : 1\n \"maxCount\" : 1\n },\n {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n }\n ]\n }\n ]\n }\n ]\n}\nIn the previous section, the circuit schema example already introduces a bit the way a shape can be specialized. Indeed combining shapes using the and boolean operator conveys a sense of extension. But the specialization can go further than just adding more constraints on top of a reused schema. The this:Circuit can further constraint the use of the schema:description property in all bbp:Circuit instances by setting a minimal and a mawimal cardinality. All bbp:Circuit instances must have exactly one value for the property schema:description whereas it’s not mandatory for other bbp:Entity instances.\nNote that only the and boolean operator can be used for shape specialization.","title":"Shape specialization"},{"location":"/docs/shacl-tutorial/overview/constraints.html#frequent-shacl-validation-errors","text":"WIP","title":"Frequent SHACL validation errors"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_shape-target.html","text":"","title":"Target declarations ?"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_shape-target.html#target-declarations-","text":"A shape can define the nodes it will selects in a given data graph and validate. It does so by declaring a target.\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Entity\",\n \"@type\" : \"sh:NodeShape\",\n \"description\" : \"A node shape.\",\n \"targetClass\" : \"prov:Entity\"\n } ]\n}","title":"Target declarations ?"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_shape-target.html#shape","text":"How a shape works? SHACL Validation flow\nGiven an input data graph (a json-ld document):\nNode to be focused on for validation are selected using targets: list the different targets Filters can be used to eliminate some focused nodes Validate focused nodes using constraints","title":"Shape"},{"location":"/docs/shacl-tutorial/further-readings/_index.html","text":"","title":"Overview"},{"location":"/docs/shacl-tutorial/further-readings/_index.html#overview","text":"much to learn you still have","title":"Overview"},{"location":"/docs/shacl-tutorial/how-to/_reuse-a-shacl-schemas.html","text":"","title":"Reuse a Shacl schemas"},{"location":"/docs/shacl-tutorial/how-to/_reuse-a-shacl-schemas.html#reuse-a-shacl-schemas","text":"","title":"Reuse a Shacl schemas"},{"location":"/docs/shacl-tutorial/nexus-kg-schemas/_index.html","text":"","title":"Nexus KG schemas"},{"location":"/docs/shacl-tutorial/nexus-kg-schemas/_index.html#nexus-kg-schemas","text":"","title":"Nexus KG schemas"},{"location":"/docs/shacl-tutorial/further-readings/_what-is-shacl.html","text":"","title":"What is SHACL ?"},{"location":"/docs/shacl-tutorial/further-readings/_what-is-shacl.html#what-is-shacl-","text":"shapes RDF","title":"What is SHACL ?"},{"location":"/docs/shacl-tutorial/how-to/_write-shacl-schemas.html","text":"","title":"Write a good shacl schemas"},{"location":"/docs/shacl-tutorial/how-to/_write-shacl-schemas.html#write-a-good-shacl-schemas","text":"","title":"Write a good shacl schemas"},{"location":"/docs/shacl-tutorial/tutorial-example/grow-refine.html","text":"","title":"Grow Refine"},{"location":"/docs/shacl-tutorial/tutorial-example/grow-refine.html#grow-refine","text":"Let start out with very simple descriptions of the entities in the little publishing domain.","title":"Grow Refine"},{"location":"/docs/shacl-tutorial/tutorial-example/grow-refine.html#researcher-description","text":"A Researcher can be described by a givenName, a familyName as well as its affiliations.\n{\n \"@context\":\"http://schema.org\",\n \"@type\" : \"Person\",\n \"giveName\" : \"Alice\",\n \"familyName\" : \"Alice\",\n \"affiliations\":[]\n}\nProperty Description familyName The researcher family name givenName The researcher given name affiliations The institutions (labs, universities,…) the researcher is affiliated to identifier The researcher persistent digital identifier orcid identifiers","title":"Researcher description"},{"location":"/docs/shacl-tutorial/tutorial-example/grow-refine.html#organization-description","text":"Hopefully To help answer the above questions, the following datasets will be used:","title":"Organization description"},{"location":"/docs/shacl-tutorial/tutorial-example/grow-refine.html#grant-description","text":"","title":"Grant description"},{"location":"/docs/shacl-tutorial/tutorial-example/grow-refine.html#scientific-publication-description","text":"","title":"Scientific Publication description"},{"location":"/docs/shacl-tutorial/tutorial-example/little-publishing-domain.html","text":"","title":"A little Academic Publishing Domain"},{"location":"/docs/shacl-tutorial/tutorial-example/little-publishing-domain.html#a-little-academic-publishing-domain","text":"","title":"A little Academic Publishing Domain"},{"location":"/docs/shacl-tutorial/tutorial-example/little-publishing-domain.html#get-started","text":"The produced domain model should support the following queries: that is to say the competency questions.\nGet the researcher’s description Get the researcher’s area of studies Get the researcher’s affiliations Get the researcher’s publications Get the researcher’s current and past grants\nTo answer the above questions, the following entities need to be considered:\nResearcher Researchers’ affiliations which are organisations Research Grant Scientific Publication","title":"Get started"},{"location":"/docs/shacl-tutorial/tutorial-example/little-publishing-domain.html#knowledge-graph-perspective","text":"Let adopt a knowledge graph perspective to illustrate this domain:\nEach of the above entities needs to be described using a given set of properties.\nAll of the above entities can be described using metadata from schema.org.","title":"Knowledge graph perspective"},{"location":"/docs/shacl-tutorial/tutorial-example/little-publishing-domain.html#modelling","text":"A simple model A comple model","title":"Modelling"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html","text":"","title":"Validation flow"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#validation-flow","text":"Given a RDF data graph, a SHACL validator:\nfirst selects nodes to validate using target declaration validates selected nodes with respect to constraints defined in the form of shapes and finally produces a validation report indicating which nodes was selected (if any) and how well they match the defined shapes","title":"Validation flow"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#target-declaration","text":"A shape can define the nodes it will select and validate in a given data graph. It does so by declaring a target. Four different target declarations exist in SHACL as described in the following sections:\nNode target using the key targetNode Class target using the key targetClass Property Subject target using the key targetSubjectsOf Property Object target using the key targetObjectsOf\nNote that selected nodes for every target below are identified by a green line color.","title":"Target declaration"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#node-target","text":"A shape can target very specific instances (nodes) by specifying their URIs through a targetNode:\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/Circuit_1_2\",\n \"@type\" : \"sh:Node Shape\",\n \"targetNode\" : [\"bbp:Circuit_1\",\"bbp:Circuit_2\"]\n } ]\n}\nThe instances identified by bbp:Circuit_1 and bbp:Circuit_2 are targeted in the figure above.","title":"Node target"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#class-target","text":"The following schema defines one node shape which targets all instances of the class bbp:Entity. So only nodes that has bbp:Entity as direct type (**bb:Entity_1**) or indirect type (**bbp:Circuit_1** and bbp:Circuit_2) will be validated while all the other nodes are ignored.\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/Entity\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Entity\"\n } ]\n}","title":"Class target"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#property-object-target","text":"A shape can target nodes that are objects of a specific property through targetObjectsOf.\nThis target will select any node that participate to the following triple as object: (subject, property, SelectedNode). In the figure below, there are two selected nodes (**bbp:Morphology_1** and bbp:Morphology_2) which respectively participate to the following two triples:\n*(bbp:Circuit_1, bbp:morphology, bbp:Morphology_1) *(bbp:Circuit_2, bbp:morphology, bbp:Morphology_2)\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertyObject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetObjectsOf\" : \"bbp:morphology\"\n } ]\n}","title":"Property Object target"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#property-subject-target","text":"This target is the subject counterpart of the previous one. A shape can target nodes that are subjects of a specific property through targetSubjectsOf. So any nodes that are subjects of a triple with the target property as predicate will be selected: (**SelectedNode**, property, object).\nIn the figure below, there are two selected nodes (**bbp:Circuit_1** and bbp:Circuit_2) which respectively participate to the following two triples:\n(**bbp:Circuit_1**, bbp:morphology, bbp:Morphology_1) (**bbp:Circuit_2**, bbp:morphology, bbp:Morphology_2)\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertySubject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetSubjectsOf\" : \"bbp:morphology\"\n } ]\n}","title":"Property Subject target"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#constraints","text":"A shape can defined a set of constraints to be checked against selected nodes. The set of possible constraints can be divided into two categories:\nNodeKind constraint: about selected nodes themselves Property constraints: about outgoing or incoming properties of each selected node","title":"Constraints"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#nodekind-constraint","text":"The nodeKind constraint allows to choose if a selected need to be identified by an IRI eventually consistent with a specific pattern or if it can unidentified. At most one nodeKind constraint can be defined for a given NodeShape.\nThe following schema states that all values of the property bbp:morphology have to be nodes identified by IRIs.\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertyObject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetObjectsOf\" : \"bbp:morphology\",\n \"nodeKind\": \"sh:IRI\"\n } ]\n}\nIn the previous example, the node “Morphology_1” (red border) is an object of the property bbp:morphology which is a Literal (precisely a string literal). So it’s not identifier by an IRI which makes it invalid. The node bbp:Morphology_2 (green border) on the other hand is valid because it is an object property of the property bbp:morphology and is identified by an IRI. All values of the nodeKind constraint are listed in the table below:\nValue Description sh:IRI The selected nodes have to be identified by a valid IRI. sh:BlankNode The selected nodes should not be identified by an IRI nor be a Literal. sh:Literal The selected nodes should be a Literal. sh:BlankNodeOrIRI Disjunctive combination of sh:BlankNode and sh:IRI. sh:BlankNodeOrLiteral Disjunctive combination of sh:BlankNode and sh:Literal. sh:IRIOrLiteral Disjunctive combination of sh:IRI and sh:Literal.","title":"NodeKind Constraint"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#property-constraints","text":"Definition of bbp:morphology as an outgoing property of any instance of bbp:Circuit:\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\"\n }\n } ]\n ]\n}\nGiven a selected node, a shape defines a set of outgoing and/or incoming properties as well as a set of constraints for each of them. By doing so, a shape enforce a vocabulary (a set of properties) to be used for describing the selected nodes (instances of bbp:Circuit in the schema for example) and how that vocabulary should be used (constraints).\nTo define a set of incoming and/or outgoing properties, the “property” key is used. It is an array and each of its item is an instance of a PropertyShape. The following tables describe the minimal keys to use in order to define a property:\nkey Description path Mandatory. Refers to the property IRI (“bbp:morphology” in the schema example) in case of outgoing property. For an incoming one, the following syntax is used: “path” : [ “sh:inversePath prov:generated” ]. name Optional. A human readable name of the property. The name can be used in generated forms for example. description Optional. Description of the property.\nOnce the property shape is defined, a set of constraints can be attached to it.","title":"Property Constraints"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#cardinality-constraints","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:dataSpace\",\n \"name\" : \"Data Space\",\n \"description\" : \"Data Space.\",\n \"minCount\":\"1\"\n }\n ]\n }\n ]\n}\nHow many outgoing “bbp:morphology” properties a specific bbp:Circuit instance can have ? A question that can be reformulated as: how many triples following the pattern (bbp:Circuit_*, bbp:morphology, object) can exist in the data graph ? The answers can be: zero or more, exactly one, at most one. To enforce one of these answers a cardinality constraint can be defined and attached to a property shape as shown in the schema example. The default value for minCount and maxCount is 0.\nThe example schema states that all instances of bbp:Circuit should have at least one value for bbp:morphology property and at most 3 values. They should have at least one value for bbp:dataSpace property as well. In the example data graph below, bbp:Circuit_1 is valid because it has one value for bbp:morphology property and one value for bbp:dataSpace. On the other hand, bbp:Circuit_2 is not valid because it has not a value for bbp:dataSpace property.","title":"Cardinality Constraints"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#property-value-type-constraints","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:dataSpace\",\n \"name\" : \"Data Space\",\n \"description\" : \"Data Space.\",\n \"minCount\":\"1\"\n },\n {\n \"path\" : \"bbp:brainRegion\",\n \"name\" : \"Brain region\",\n \"description\" : \"Brain region.\",\n \"rootClass\":\"bbp:BrainRegionRootClass\",\n \"node\": \"circuitshape:LabeledOntologyTermShape\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"schema:name\",\n \"name\" : \"Name\",\n \"description\" : \"Circuit name\",\n \"datatype\": \"xsd:string\",\n \"minCount\":\"1\",\n \"maxCount\":\"1\"\n }\n ]\n },\n {\n \"@id\" : \"circuitshape:LabeledOntologyTermShape\",\n \"@type\" : \"sh:NodeShape\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"rdfs:label\",\n \"name\" : \"label\",\n \"description\" : \"Human readable label\",\n \"datatype\": \"xsd:string\",\n \"maxCount\" : 1,\n \"minCount\" : 1\n\n }\n }\n ]\n}\nThe type of a property value can be restricted. In the schema example, all instances of bbp:circuit should have exactly one name which should be of type string. How to express such type restriction in a shacl schema ?\nPrimitive type as property value\nA property value can be of a primitive type: string, integer, double, anyURI, … and datatype key is used to define such primitive expected types as shown in the shacl schema example. The namespace of all primitive types is xsd and for a complete list of those types please check here.\nProperty values are not always primitive and two other typical situations may occurs.\nReference as property value\nThe type of a property value can be restricted to be an instance of a specific class. For example, it may be useful to enforce all values of the bbp:morphology property of a given circuit to be of type bbp:Morphology. To express this type of constraint the key class is used as shown in the schema example. The ability to constraint types is important to ensure the quality and reliability of the data being submitted into the Nexus platform and SHACL allows to do that without writing a single line of validation code.\nThe class constraint doesn’t cover the case where a class (and not an instance) is used as a property value. In such situation, the constraint to express in the schema is no longer a property value to be an instance of a class but to be a subClassOf of a class.\nThis is not exactly a common use case in RDF area and that’s why it’s not part of the SHACL specification. But it’s well known that in life sciences, data are usually annotated with classes (like brain regions, cell types, …) and not with instances (classes-as-values).\nSo, the Nexus platform extended the SHACL specification to allow users to express the subClassOf constraint using the rootClass as shown in the bbp:brainRegion property shape.\nNode as property value\nSometimes it may be useful to enforce that a property value has a particular shape instead (or in addition) of being of a specific type. For example, we may want to enforce all brain region values of a all circuits (instances of bbp:Circuit) to have at least an IRI as identifier (“nodeKind”: “sh:IRI”) and a label as human readable description. The key node is used to express a shape constraint.","title":"Property Value Type Constraints"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#qualified-cardinality","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"3\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:morphology\",\n \"qualifiedValueShape\": {\n \"class\" : \"bbp:RawMorphology\"\n },\n \"qualifiedValueShapesDisjoint\": true,\n \"qualifiedMinCount\":1,\n \"qualifiedMaxCount\":1\n },\n {\n \"path\" : \"bbp:morphology\",\n \"qualifiedValueShape\": {\n \"class\" : \"bbp:SynthesizedMorphology\"\n },\n \"qualifiedValueShapesDisjoint\": true,\n \"qualifiedMinCount\":1\n }\n ]\n }\n ]\n}\nCardinality constraints can be more complex than what is presented in the constraints section above. A complex cardinality use case can be expressed in the following way : *a bbp:Circuit instance should be linked with exactly 3 Morphologies (instances of bbp:Morphology) *exactly one of them should be a raw morphology (an instance of bbp:RawMorphology) *at least one of them should be synthesized morphology (an instance of bbp:SynthesizedMorphology) *and a bbp:Circuit instance can’t be at the same time of type bbp:RawMorphology and bbp:SynthesizedMorphology\nThe schema example shows how to implement the above constraints using the following keys:\nkey Description qualifiedValueShape Mandatory. The shape that the specified (through qualifiedMinCount and qualifiedMaxCount) number of nodes should be consistent with. qualifiedMinCount Mandatory. The minimum number of nodes that should be consistent with the shape in qualifiedValueShape qualifiedMaxCount Mandatory. The maximum number of nodes that should be consistent with the shape in qualifiedValueShape qualifiedValueShapesDisjoint Optional. If true then the values conform to the current property shape must not conform to the siblings property shapes","title":"Qualified Cardinality"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#combining-shapes","text":"Until now we’ve described how to define a shape that targets different nodes using different selectors and enforcing different type of constraints. But designing real life schemas is complex and often required reuse of already defined ones. Two use cases can occur when it comes to reuse SHACL schemas:\nreuse a shape by combining it with other shapes using boolean operators specialization mechanism between shapes","title":"Combining shapes"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#logical-combination-of-shapes","text":"A node shape definition for all instances of bbp:Entity\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"this:EntityShape\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Entity\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [{\n \"path\" : \"schema:name\",\n \"name\" : \"Name\",\n \"description\" : \"Entity name\",\n \"or\":[\n {\n \"datatype\": \"xsd:string\"\n },\n {\n \"datatype\": \"xsd:integer\"\n }\n ]\n },{\n \"path\" : \"schema:description\",\n \"name\" : \"Description\",\n \"description\" : \"The entity description\",\n \"datatype\" : \"xsd:string\"\n }\n ]\n }\n ]\n}\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"@type\": \"owl:Ontology\",\n \"imports\" : [ \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\"],\n \"shapes\" : [ {\n \"@id\" : \"this:Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"and\":[{\n \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\"\n },\n {\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n }\n ]\n }\n ]\n }\n ]\n}\nShapes can be combined using the following boolean operators:\nkey Description and The data has to be valid with respect to all combined shapes or The data has to be valid with respect to at least one shape xone The data has to be valid with respect to only one shape not The data should not be valid with respect to the given shape(s)\nIn the previous schema (identified by {endpoint}/schemas/bbp/simulation/circuit/v1.0.0/), the property shape related to schema:name property can be externalized in a schema ({endpoint}/schemas/bbp/core/entity/v1.0.0/) belonging to the “bbp” organization, “core” domain and named “entity” as shown in the right tab. Now let reuse (see in the right) the entity schema since a bbp:Circuit is a bbp:Entity as well. Basically, the schema is expressing that a bbp:Circuit instance should be consistent with respect to the schema for bbp:Entity (external one) and the one for bbp:Circuit (local one).\nNote the use of the **imports** key. It tells the shacl validator where to find the shapes that are referenced in the local schema: \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\" for example. Only published schemas can be imported.\nThe or, xone and not operators can be used in the same way as the and one. The example shows how to logically combined two node shapes. Property shapes can be combined as well as shown in the shape this:EntityShape where the property schema:name van be of type string of integer.\nAll shapes that are listed in the shapes array are by default considered combined in conjunctive way (and operator).","title":"Logical combination of shapes"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#shape-specialization","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"@type\": \"owl:Ontology\",\n \"imports\" : [ \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\"],\n \"shapes\" : [ {\n \"@id\" : \"this:Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"and\":[{\n \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\"\n },\n {\n \"property\" : [\n {\n \"path\" : \"schema:description\",\n \"minCount\" : 1\n \"maxCount\" : 1\n },\n {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n }\n ]\n }\n ]\n }\n ]\n}\nIn the previous section, the circuit schema example already introduces a bit the way a shape can be specialized. Indeed combining shapes using the and boolean operator conveys a sense of extension. But the specialization can go further than just adding more constraints on top of a reused schema. The this:Circuit can further constraint the use of the schema:description property in all bbp:Circuit instances by setting a minimal and a mawimal cardinality. All bbp:Circuit instances must have exactly one value for the property schema:description whereas it’s not mandatory for other bbp:Entity instances.\nNote that only the and boolean operator can be used for shape specialization.","title":"Shape specialization"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#frequent-shacl-validation-errors","text":"WIP","title":"Frequent SHACL validation errors"},{"location":"/docs/shacl-tutorial/namespaces.html","text":"","title":"Namespaces declaration"},{"location":"/docs/shacl-tutorial/namespaces.html#namespaces-declaration","text":"This document explains web user interfaces and application programming interfaces that were developed by Neuroinformatics Platform (NIP) during the Ramp-Up phase of the Human Brain Project (HBP) that took place between October 2013 and March 2016. The applications are directly available for users and their first versions were launched at the end of the Ramp-Up phase.","title":"Namespaces declaration"}]} \ No newline at end of file +{"docs":[{"location":"/paradox.json","text":"","title":""},{"location":"/docs/shacl-tutorial/tutorial-example/little-publishing-domain.html","text":"","title":"A little Academic Publishing Domain"},{"location":"/docs/shacl-tutorial/tutorial-example/little-publishing-domain.html#a-little-academic-publishing-domain","text":"","title":"A little Academic Publishing Domain"},{"location":"/docs/shacl-tutorial/tutorial-example/little-publishing-domain.html#get-started","text":"The produced domain model should support the following queries: that is to say the competency questions.\nGet the researcher’s description Get the researcher’s area of studies Get the researcher’s affiliations Get the researcher’s publications Get the researcher’s current and past grants\nTo answer the above questions, the following entities need to be considered:\nResearcher Researchers’ affiliations which are organisations Research Grant Scientific Publication","title":"Get started"},{"location":"/docs/shacl-tutorial/tutorial-example/little-publishing-domain.html#knowledge-graph-perspective","text":"Let adopt a knowledge graph perspective to illustrate this domain:\nEach of the above entities needs to be described using a given set of properties.\nAll of the above entities can be described using metadata from schema.org.","title":"Knowledge graph perspective"},{"location":"/docs/shacl-tutorial/tutorial-example/little-publishing-domain.html#modelling","text":"A simple model A comple model","title":"Modelling"},{"location":"/docs/data-models/neuronclassification/literature.html","text":"","title":"Literature"},{"location":"/docs/data-models/neuronclassification/literature.html#literature","text":"","title":"Literature"},{"location":"/docs/data-models/neuronclassification/literature.html#use-cases","text":"List of use cases: TBD","title":"Use cases"},{"location":"/docs/data-models/neuronclassification/literatureannotation.html","text":"","title":"Literature Annotation"},{"location":"/docs/data-models/neuronclassification/literatureannotation.html#literature-annotation","text":"","title":"Literature Annotation"},{"location":"/docs/data-models/neuronclassification/literatureannotation.html#a-motivating-example","text":"","title":"A motivating example"},{"location":"/docs/data-models/neuronclassification/literatureannotation.html#description","text":"We want to be able to get, from a parameter type, all the data that are in the corpus. From this raw “dump”, we will use NAT for performing the various post-treatments to generate parameter aggregation. Parameter aggregations will need to be registered to Nexus and queried back from Nexus.","title":"Description"},{"location":"/docs/data-models/neuronclassification/literatureannotation.html#competency-questions","text":"Annotation: Get all annotations Get annotations by parameter type (labels ?) Get annotation by id Get annotation by article id (doi,…) Parameter: Get all parameters Get parameters by type Get parameters by annotation id","title":"Competency questions"},{"location":"/docs/data-models/neuronclassification/literatureannotation.html#abstract-data-model","text":"","title":"Abstract Data model"},{"location":"/docs/data-models/neuronclassification/annotation.html","text":"Happy to present @INCForg #Neuroshapes Special Interest Group for #FAIR #neuroscience #data on August 8, 2:30-5:30pm during the @brainhackorg hackathon! We’ll talking about neuroscience data #reusability and #interoperability. Join us https://brainhackmtl.github.io/informatics2018/#schedule","title":"NI2018 #neuroinformagical #semanticweb #shacl"},{"location":"/docs/data-models/neuronclassification/annotation.html#ni2018-neuroinformagical-semanticweb-shacl","text":"","title":"NI2018 #neuroinformagical #semanticweb #shacl"},{"location":"/docs/data-models/neuronclassification/parameter.html","text":"","title":"Parameter"},{"location":"/docs/data-models/neuronclassification/parameter.html#parameter","text":"","title":"Parameter"},{"location":"/docs/data-models/neuronclassification/parameter.html#use-cases","text":"List of use cases: TBD","title":"Use cases"},{"location":"/docs/data-models/neuronclassification/provenance.html","text":"","title":"Provenance"},{"location":"/docs/data-models/neuronclassification/provenance.html#provenance","text":"","title":"Provenance"},{"location":"/docs/data-models/neuronclassification/provenance.html#use-cases","text":"List of use cases: TBD","title":"Use cases"},{"location":"/docs/data-models/literature/literature.html","text":"","title":"Literature"},{"location":"/docs/data-models/literature/literature.html#literature","text":"","title":"Literature"},{"location":"/docs/data-models/literature/literature.html#use-cases","text":"List of use cases: TBD","title":"Use cases"},{"location":"/docs/data-models/literature/literatureannotation.html","text":"","title":"Literature Annotation"},{"location":"/docs/data-models/literature/literatureannotation.html#literature-annotation","text":"","title":"Literature Annotation"},{"location":"/docs/data-models/literature/literatureannotation.html#a-motivating-example","text":"","title":"A motivating example"},{"location":"/docs/data-models/literature/literatureannotation.html#description","text":"We want to be able to get, from a parameter type, all the data that are in the corpus. From this raw “dump”, we will use NAT for performing the various post-treatments to generate parameter aggregation. Parameter aggregations will need to be registered to Nexus and queried back from Nexus.","title":"Description"},{"location":"/docs/data-models/literature/literatureannotation.html#competency-questions","text":"Annotation: Get all annotations Get annotations by parameter type (labels ?) Get annotation by id Get annotation by article id (doi,…) Parameter: Get all parameters Get parameters by type Get parameters by annotation id","title":"Competency questions"},{"location":"/docs/data-models/literature/literatureannotation.html#abstract-data-model","text":"","title":"Abstract Data model"},{"location":"/docs/data-models/literature/annotation.html","text":"","title":"Annotation"},{"location":"/docs/data-models/literature/annotation.html#annotation","text":"","title":"Annotation"},{"location":"/docs/data-models/literature/annotation.html#use-cases","text":"List of use cases: TBD","title":"Use cases"},{"location":"/docs/data-models/literature/parameter.html","text":"","title":"Parameter"},{"location":"/docs/data-models/literature/parameter.html#parameter","text":"","title":"Parameter"},{"location":"/docs/data-models/literature/parameter.html#use-cases","text":"List of use cases: TBD","title":"Use cases"},{"location":"/docs/data-models/literature/provenance.html","text":"","title":"Provenance"},{"location":"/docs/data-models/literature/provenance.html#provenance","text":"","title":"Provenance"},{"location":"/docs/data-models/literature/provenance.html#use-cases","text":"List of use cases: TBD","title":"Use cases"},{"location":"/docs/shacl-tutorial/how-to/_reuse-a-shacl-schemas.html","text":"","title":"Reuse a Shacl schemas"},{"location":"/docs/shacl-tutorial/how-to/_reuse-a-shacl-schemas.html#reuse-a-shacl-schemas","text":"","title":"Reuse a Shacl schemas"},{"location":"/docs/shacl-tutorial/tutorial-example/grow-refine.html","text":"","title":"Grow Refine"},{"location":"/docs/shacl-tutorial/tutorial-example/grow-refine.html#grow-refine","text":"Let start out with very simple descriptions of the entities in the little publishing domain.","title":"Grow Refine"},{"location":"/docs/shacl-tutorial/tutorial-example/grow-refine.html#researcher-description","text":"A Researcher can be described by a givenName, a familyName as well as its affiliations.\n{\n \"@context\":\"http://schema.org\",\n \"@type\" : \"Person\",\n \"giveName\" : \"Alice\",\n \"familyName\" : \"Alice\",\n \"affiliations\":[]\n}\nProperty Description familyName The researcher family name givenName The researcher given name affiliations The institutions (labs, universities,…) the researcher is affiliated to identifier The researcher persistent digital identifier orcid identifiers","title":"Researcher description"},{"location":"/docs/shacl-tutorial/tutorial-example/grow-refine.html#organization-description","text":"Hopefully To help answer the above questions, the following datasets will be used:","title":"Organization description"},{"location":"/docs/shacl-tutorial/tutorial-example/grow-refine.html#grant-description","text":"","title":"Grant description"},{"location":"/docs/shacl-tutorial/tutorial-example/grow-refine.html#scientific-publication-description","text":"","title":"Scientific Publication description"},{"location":"/docs/data-models/minds/model.html","text":"","title":"Abstract Data Model"},{"location":"/docs/data-models/minds/model.html#abstract-data-model","text":"List of use cases: TBD","title":"Abstract Data Model"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html","text":"","title":"Best Practices"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#best-practices","text":"","title":"Best Practices"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#node-shapes-identifiers","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/CircuitShape\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"property\":[{\n \"@id\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/ConnectomeShape\",\n \"path\": \"bbpprodprop:connectome\"\n \"name\": \"Connectome\",\n \"description\": \"Connectome\",\n \"datatype\": \"xsd:string\",\n \"maxCount\": 1,\n \"minCount\": 0\n }\n ]\n }\n ]\n}\nIt is strongly recommended to provide identifiers (value for @id) for the node shapes (things of type sh:NodeShape) so that they can be reused and discovered through the Nexus Rest API.\nBoth node shapes and property shapes can have identifiers.\nA property shape needs to have an identifier only if there is a need to reuse it.","title":"Node shapes identifiers"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#nexus-schema-annotations","text":"Schemas are often designed with reuse in mind. Good annotations is key in order to enable schema discoverability and reuse. The following list presents a set of recommended annotations that one can use to describe a schema:\n…WIP","title":"Nexus schema annotations"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#shape-annotations","text":"","title":"SHAPE annotations"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#node-shape-annotations","text":"Node shapes are shapes with type sh:NodeShape. It is recommended that a node shape is annotated with the following properties:\nKey Description label A human readable label for the node shape. This property is a short form for rdfs:label. comment A human readable description of the node shape.This property is a short form for rdfs:comment.","title":"Node shape annotations"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#property-shape-annotations","text":"Property shapes are shapes with type sh:PropertyShape. It is recommended that a property shape is annotated with the following properties:\nKey Description name A human readable name for the shape. The name is usually displayed when a form is generated from the shape description A human readable description of the shape. Also used in form generation\nAnnotation properties are not taken into accoiunt during validation.","title":"Property shape annotations"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#shape-keys-ordering","text":"To improve the SHACL schema readability, it is recommended to adopt the following ordering when defining:\na Node Shape\nOrder Key Description 1 @id Always start with the node shape identifier if any 2 @type The node shape type 3 label A human readable description of the node shape. 4 comment A description of the node shape. 5 target(Class-Node-ObjectsOf-SubjectsOf) The node shape target 6 nodeKind The node shape node kind 7 property The node shape properties\na Property Shape\nOrder Key Description 1 @id Always start with the property shape identifier if any. Most of the time, there is no need to have an identifier for a property shape 2 @type The property shape type. Most of the time, there is no need to add a type to a property shape 3 path The property targeted by the property shape. 4 name A human readable name for the property shape. 5 description A human readable description of the property shape. 6 nodeKind The property shape node kind. Cannot be present when datatype is present. 7 class or datatype These two keys are mutually exclusive. THus they can occurs in the same property shape at the same time. Every value of the targeted property (defined in path) should have the value of class or datatype as type 8 node Always has a node shape as value. Every value of the targeted property (defined in path) should conform to the referenced node shape. 9 minCount or maxCount Cardinality constraints.","title":"SHAPE keys ordering"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#naming-conventions","text":"","title":"Naming conventions"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#class-name-as-single-noun","text":"In schemas, classes (values of targetClass, of @type) are named using camel case notation:\nclass name should start with a capital letter class name should be singular no space is allowed good examples: “bbp:Circuit”, bbp:RawMorphology bad examples: “bbp:Circuits”, “bbp:circuit” but also “bbp:Raw_Morphology”","title":"Class name as single noun"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#instance-name-as-single-noun","text":"Instances naming follows the same conventions as class naming. In a schemas, instances are things that have a type (@type): mainly the shapes (node and property shapes).","title":"Instance name as single noun"},{"location":"/docs/shacl-tutorial/overview/shape-best-practices.html#property-name-as-verb-sense-or-single-noun","text":"In schemas, properties (mainly values of sh:path) are named using the following convention:\nproperty name should start with lower case and be capitalized thereafter property name should be singular no space is allowed good example: “bbp:morphology”, “bbp:hasFileExtension” or “bbp:fileExtension” bad examples: “bbp:morphologies” but also “bbp:segment_index”","title":"Property name as verb sense or single noun"},{"location":"/docs/data-models/minds/ontology.html","text":"","title":"Ontology"},{"location":"/docs/data-models/minds/ontology.html#ontology","text":"List of use cases: TBD","title":"Ontology"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html","text":"","title":"Validation flow"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#validation-flow","text":"Given a RDF data graph, a SHACL validator:\nfirst selects nodes to validate using target declaration validates selected nodes with respect to constraints defined in the form of shapes and finally produces a validation report indicating which nodes was selected (if any) and how well they match the defined shapes","title":"Validation flow"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#target-declaration","text":"A shape can define the nodes it will select and validate in a given data graph. It does so by declaring a target. Four different target declarations exist in SHACL as described in the following sections:\nNode target using the key targetNode Class target using the key targetClass Property Subject target using the key targetSubjectsOf Property Object target using the key targetObjectsOf\nNote that selected nodes for every target below are identified by a green line color.","title":"Target declaration"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#node-target","text":"A shape can target very specific instances (nodes) by specifying their URIs through a targetNode:\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/Circuit_1_2\",\n \"@type\" : \"sh:Node Shape\",\n \"targetNode\" : [\"bbp:Circuit_1\",\"bbp:Circuit_2\"]\n } ]\n}\nThe instances identified by bbp:Circuit_1 and bbp:Circuit_2 are targeted in the figure above.","title":"Node target"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#class-target","text":"The following schema defines one node shape which targets all instances of the class bbp:Entity. So only nodes that has bbp:Entity as direct type (**bb:Entity_1**) or indirect type (**bbp:Circuit_1** and bbp:Circuit_2) will be validated while all the other nodes are ignored.\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/Entity\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Entity\"\n } ]\n}","title":"Class target"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#property-object-target","text":"A shape can target nodes that are objects of a specific property through targetObjectsOf.\nThis target will select any node that participate to the following triple as object: (subject, property, SelectedNode). In the figure below, there are two selected nodes (**bbp:Morphology_1** and bbp:Morphology_2) which respectively participate to the following two triples:\n*(bbp:Circuit_1, bbp:morphology, bbp:Morphology_1) *(bbp:Circuit_2, bbp:morphology, bbp:Morphology_2)\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertyObject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetObjectsOf\" : \"bbp:morphology\"\n } ]\n}","title":"Property Object target"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#property-subject-target","text":"This target is the subject counterpart of the previous one. A shape can target nodes that are subjects of a specific property through targetSubjectsOf. So any nodes that are subjects of a triple with the target property as predicate will be selected: (**SelectedNode**, property, object).\nIn the figure below, there are two selected nodes (**bbp:Circuit_1** and bbp:Circuit_2) which respectively participate to the following two triples:\n(**bbp:Circuit_1**, bbp:morphology, bbp:Morphology_1) (**bbp:Circuit_2**, bbp:morphology, bbp:Morphology_2)\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertySubject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetSubjectsOf\" : \"bbp:morphology\"\n } ]\n}","title":"Property Subject target"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#constraints","text":"A shape can defined a set of constraints to be checked against selected nodes. The set of possible constraints can be divided into two categories:\nNodeKind constraint: about selected nodes themselves Property constraints: about outgoing or incoming properties of each selected node","title":"Constraints"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#nodekind-constraint","text":"The nodeKind constraint allows to choose if a selected need to be identified by an IRI eventually consistent with a specific pattern or if it can unidentified. At most one nodeKind constraint can be defined for a given NodeShape.\nThe following schema states that all values of the property bbp:morphology have to be nodes identified by IRIs.\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertyObject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetObjectsOf\" : \"bbp:morphology\",\n \"nodeKind\": \"sh:IRI\"\n } ]\n}\nIn the previous example, the node “Morphology_1” (red border) is an object of the property bbp:morphology which is a Literal (precisely a string literal). So it’s not identifier by an IRI which makes it invalid. The node bbp:Morphology_2 (green border) on the other hand is valid because it is an object property of the property bbp:morphology and is identified by an IRI. All values of the nodeKind constraint are listed in the table below:\nValue Description sh:IRI The selected nodes have to be identified by a valid IRI. sh:BlankNode The selected nodes should not be identified by an IRI nor be a Literal. sh:Literal The selected nodes should be a Literal. sh:BlankNodeOrIRI Disjunctive combination of sh:BlankNode and sh:IRI. sh:BlankNodeOrLiteral Disjunctive combination of sh:BlankNode and sh:Literal. sh:IRIOrLiteral Disjunctive combination of sh:IRI and sh:Literal.","title":"NodeKind Constraint"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#property-constraints","text":"Definition of bbp:morphology as an outgoing property of any instance of bbp:Circuit:\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\"\n }\n } ]\n ]\n}\nGiven a selected node, a shape defines a set of outgoing and/or incoming properties as well as a set of constraints for each of them. By doing so, a shape enforce a vocabulary (a set of properties) to be used for describing the selected nodes (instances of bbp:Circuit in the schema for example) and how that vocabulary should be used (constraints).\nTo define a set of incoming and/or outgoing properties, the “property” key is used. It is an array and each of its item is an instance of a PropertyShape. The following tables describe the minimal keys to use in order to define a property:\nkey Description path Mandatory. Refers to the property IRI (“bbp:morphology” in the schema example) in case of outgoing property. For an incoming one, the following syntax is used: “path” : [ “sh:inversePath prov:generated” ]. name Optional. A human readable name of the property. The name can be used in generated forms for example. description Optional. Description of the property.\nOnce the property shape is defined, a set of constraints can be attached to it.","title":"Property Constraints"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#cardinality-constraints","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:dataSpace\",\n \"name\" : \"Data Space\",\n \"description\" : \"Data Space.\",\n \"minCount\":\"1\"\n }\n ]\n }\n ]\n}\nHow many outgoing “bbp:morphology” properties a specific bbp:Circuit instance can have ? A question that can be reformulated as: how many triples following the pattern (bbp:Circuit_*, bbp:morphology, object) can exist in the data graph ? The answers can be: zero or more, exactly one, at most one. To enforce one of these answers a cardinality constraint can be defined and attached to a property shape as shown in the schema example. The default value for minCount and maxCount is 0.\nThe example schema states that all instances of bbp:Circuit should have at least one value for bbp:morphology property and at most 3 values. They should have at least one value for bbp:dataSpace property as well. In the example data graph below, bbp:Circuit_1 is valid because it has one value for bbp:morphology property and one value for bbp:dataSpace. On the other hand, bbp:Circuit_2 is not valid because it has not a value for bbp:dataSpace property.","title":"Cardinality Constraints"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#property-value-type-constraints","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:dataSpace\",\n \"name\" : \"Data Space\",\n \"description\" : \"Data Space.\",\n \"minCount\":\"1\"\n },\n {\n \"path\" : \"bbp:brainRegion\",\n \"name\" : \"Brain region\",\n \"description\" : \"Brain region.\",\n \"rootClass\":\"bbp:BrainRegionRootClass\",\n \"node\": \"circuitshape:LabeledOntologyTermShape\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"schema:name\",\n \"name\" : \"Name\",\n \"description\" : \"Circuit name\",\n \"datatype\": \"xsd:string\",\n \"minCount\":\"1\",\n \"maxCount\":\"1\"\n }\n ]\n },\n {\n \"@id\" : \"circuitshape:LabeledOntologyTermShape\",\n \"@type\" : \"sh:NodeShape\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"rdfs:label\",\n \"name\" : \"label\",\n \"description\" : \"Human readable label\",\n \"datatype\": \"xsd:string\",\n \"maxCount\" : 1,\n \"minCount\" : 1\n\n }\n }\n ]\n}\nThe type of a property value can be restricted. In the schema example, all instances of bbp:circuit should have exactly one name which should be of type string. How to express such type restriction in a shacl schema ?\nPrimitive type as property value\nA property value can be of a primitive type: string, integer, double, anyURI, … and datatype key is used to define such primitive expected types as shown in the shacl schema example. The namespace of all primitive types is xsd and for a complete list of those types please check here.\nProperty values are not always primitive and two other typical situations may occurs.\nReference as property value\nThe type of a property value can be restricted to be an instance of a specific class. For example, it may be useful to enforce all values of the bbp:morphology property of a given circuit to be of type bbp:Morphology. To express this type of constraint the key class is used as shown in the schema example. The ability to constraint types is important to ensure the quality and reliability of the data being submitted into the Nexus platform and SHACL allows to do that without writing a single line of validation code.\nThe class constraint doesn’t cover the case where a class (and not an instance) is used as a property value. In such situation, the constraint to express in the schema is no longer a property value to be an instance of a class but to be a subClassOf of a class.\nThis is not exactly a common use case in RDF area and that’s why it’s not part of the SHACL specification. But it’s well known that in life sciences, data are usually annotated with classes (like brain regions, cell types, …) and not with instances (classes-as-values).\nSo, the Nexus platform extended the SHACL specification to allow users to express the subClassOf constraint using the rootClass as shown in the bbp:brainRegion property shape.\nNode as property value\nSometimes it may be useful to enforce that a property value has a particular shape instead (or in addition) of being of a specific type. For example, we may want to enforce all brain region values of a all circuits (instances of bbp:Circuit) to have at least an IRI as identifier (“nodeKind”: “sh:IRI”) and a label as human readable description. The key node is used to express a shape constraint.","title":"Property Value Type Constraints"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#qualified-cardinality","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"3\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:morphology\",\n \"qualifiedValueShape\": {\n \"class\" : \"bbp:RawMorphology\"\n },\n \"qualifiedValueShapesDisjoint\": true,\n \"qualifiedMinCount\":1,\n \"qualifiedMaxCount\":1\n },\n {\n \"path\" : \"bbp:morphology\",\n \"qualifiedValueShape\": {\n \"class\" : \"bbp:SynthesizedMorphology\"\n },\n \"qualifiedValueShapesDisjoint\": true,\n \"qualifiedMinCount\":1\n }\n ]\n }\n ]\n}\nCardinality constraints can be more complex than what is presented in the constraints section above. A complex cardinality use case can be expressed in the following way : *a bbp:Circuit instance should be linked with exactly 3 Morphologies (instances of bbp:Morphology) *exactly one of them should be a raw morphology (an instance of bbp:RawMorphology) *at least one of them should be synthesized morphology (an instance of bbp:SynthesizedMorphology) *and a bbp:Circuit instance can’t be at the same time of type bbp:RawMorphology and bbp:SynthesizedMorphology\nThe schema example shows how to implement the above constraints using the following keys:\nkey Description qualifiedValueShape Mandatory. The shape that the specified (through qualifiedMinCount and qualifiedMaxCount) number of nodes should be consistent with. qualifiedMinCount Mandatory. The minimum number of nodes that should be consistent with the shape in qualifiedValueShape qualifiedMaxCount Mandatory. The maximum number of nodes that should be consistent with the shape in qualifiedValueShape qualifiedValueShapesDisjoint Optional. If true then the values conform to the current property shape must not conform to the siblings property shapes","title":"Qualified Cardinality"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#combining-shapes","text":"Until now we’ve described how to define a shape that targets different nodes using different selectors and enforcing different type of constraints. But designing real life schemas is complex and often required reuse of already defined ones. Two use cases can occur when it comes to reuse SHACL schemas:\nreuse a shape by combining it with other shapes using boolean operators specialization mechanism between shapes","title":"Combining shapes"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#logical-combination-of-shapes","text":"A node shape definition for all instances of bbp:Entity\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"this:EntityShape\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Entity\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [{\n \"path\" : \"schema:name\",\n \"name\" : \"Name\",\n \"description\" : \"Entity name\",\n \"or\":[\n {\n \"datatype\": \"xsd:string\"\n },\n {\n \"datatype\": \"xsd:integer\"\n }\n ]\n },{\n \"path\" : \"schema:description\",\n \"name\" : \"Description\",\n \"description\" : \"The entity description\",\n \"datatype\" : \"xsd:string\"\n }\n ]\n }\n ]\n}\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"@type\": \"owl:Ontology\",\n \"imports\" : [ \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\"],\n \"shapes\" : [ {\n \"@id\" : \"this:Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"and\":[{\n \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\"\n },\n {\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n }\n ]\n }\n ]\n }\n ]\n}\nShapes can be combined using the following boolean operators:\nkey Description and The data has to be valid with respect to all combined shapes or The data has to be valid with respect to at least one shape xone The data has to be valid with respect to only one shape not The data should not be valid with respect to the given shape(s)\nIn the previous schema (identified by {endpoint}/schemas/bbp/simulation/circuit/v1.0.0/), the property shape related to schema:name property can be externalized in a schema ({endpoint}/schemas/bbp/core/entity/v1.0.0/) belonging to the “bbp” organization, “core” domain and named “entity” as shown in the right tab. Now let reuse (see in the right) the entity schema since a bbp:Circuit is a bbp:Entity as well. Basically, the schema is expressing that a bbp:Circuit instance should be consistent with respect to the schema for bbp:Entity (external one) and the one for bbp:Circuit (local one).\nNote the use of the **imports** key. It tells the shacl validator where to find the shapes that are referenced in the local schema: \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\" for example. Only published schemas can be imported.\nThe or, xone and not operators can be used in the same way as the and one. The example shows how to logically combined two node shapes. Property shapes can be combined as well as shown in the shape this:EntityShape where the property schema:name van be of type string of integer.\nAll shapes that are listed in the shapes array are by default considered combined in conjunctive way (and operator).","title":"Logical combination of shapes"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#shape-specialization","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"@type\": \"owl:Ontology\",\n \"imports\" : [ \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\"],\n \"shapes\" : [ {\n \"@id\" : \"this:Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"and\":[{\n \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\"\n },\n {\n \"property\" : [\n {\n \"path\" : \"schema:description\",\n \"minCount\" : 1\n \"maxCount\" : 1\n },\n {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n }\n ]\n }\n ]\n }\n ]\n}\nIn the previous section, the circuit schema example already introduces a bit the way a shape can be specialized. Indeed combining shapes using the and boolean operator conveys a sense of extension. But the specialization can go further than just adding more constraints on top of a reused schema. The this:Circuit can further constraint the use of the schema:description property in all bbp:Circuit instances by setting a minimal and a mawimal cardinality. All bbp:Circuit instances must have exactly one value for the property schema:description whereas it’s not mandatory for other bbp:Entity instances.\nNote that only the and boolean operator can be used for shape specialization.","title":"Shape specialization"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_what-is-shacl.html#frequent-shacl-validation-errors","text":"WIP","title":"Frequent SHACL validation errors"},{"location":"/docs/shacl-tutorial/overview/constraints.html","text":"","title":"Constraints"},{"location":"/docs/shacl-tutorial/overview/constraints.html#constraints","text":"Co-occurrence constraints\nA shape can defined a set of constraints to be checked against selected nodes. The set of possible constraints can be divided into two categories:\nNodeKind constraint: about selected nodes themselves Property constraints: about outgoing or incoming properties of each selected node","title":"Constraints"},{"location":"/docs/shacl-tutorial/overview/constraints.html#nodekind-constraint","text":"The nodeKind constraint allows to choose if a selected need to be identified by an IRI eventually consistent with a specific pattern or if it can unidentified. At most one nodeKind constraint can be defined for a given NodeShape.\nThe following schema states that all values of the property bbp:morphology have to be nodes identified by IRIs.\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertyObject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetObjectsOf\" : \"bbp:morphology\",\n \"nodeKind\": \"sh:IRI\"\n } ]\n}\nIn the previous example, the node “Morphology_1” (red border) is an object of the property bbp:morphology which is a Literal (precisely a string literal). So it’s not identifier by an IRI which makes it invalid. The node bbp:Morphology_2 (green border) on the other hand is valid because it is an object property of the property bbp:morphology and is identified by an IRI. All values of the nodeKind constraint are listed in the table below:\nValue Description sh:IRI The selected nodes have to be identified by a valid IRI. sh:BlankNode The selected nodes should not be identified by an IRI nor be a Literal. sh:Literal The selected nodes should be a Literal. sh:BlankNodeOrIRI Disjunctive combination of sh:BlankNode and sh:IRI. sh:BlankNodeOrLiteral Disjunctive combination of sh:BlankNode and sh:Literal. sh:IRIOrLiteral Disjunctive combination of sh:IRI and sh:Literal.","title":"NodeKind Constraint"},{"location":"/docs/shacl-tutorial/overview/constraints.html#property-constraints","text":"Definition of bbp:morphology as an outgoing property of any instance of bbp:Circuit:\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\"\n }\n } ]\n ]\n}\nGiven a selected node, a shape defines a set of outgoing and/or incoming properties as well as a set of constraints for each of them. By doing so, a shape enforce a vocabulary (a set of properties) to be used for describing the selected nodes (instances of bbp:Circuit in the schema for example) and how that vocabulary should be used (constraints).\nTo define a set of incoming and/or outgoing properties, the property key is used. It is an array and each of its item is an instance of a PropertyShape. The following tables describe the minimal keys to use in order to define a property:\nkey Description path MAandatory. Refers to the property IRI (“bbp:morphology” in the schema example) in case of outgoing property. For an incoming one, the following syntax is used: “path” : [ “sh:inversePath prov:generated” ]. name Optional. A human readable name of the property. The name can be used in generated forms for example. description Optional. Description of the property.\nOnce the property shape is defined, a set of constraints can be attached to it.\nCardinality Constraints\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:dataSpace\",\n \"name\" : \"Data Space\",\n \"description\" : \"Data Space.\",\n \"minCount\":\"1\"\n }\n ]\n }\n ]\n}\nHow many outgoing “bbp:morphology” properties a specific bbp:Circuit instance can have ? A question that can be reformulated as: how many triples following the pattern (bbp:Circuit_*, bbp:morphology, object) can exist in the data graph ? The answers can be: zero or more, exactly one, at most one. To enforce one of these answers a cardinality constraint can be defined and attached to a property shape as shown in the schema example. The default value for minCount and maxCount is 0.\nThe example schema states that all instances of bbp:Circuit should have at least one value for bbp:morphology property and at most 3 values. They should have at least one value for bbp:dataSpace property as well. In the example data graph below, bbp:Circuit_1 is valid because it has one value for bbp:morphology property and one value for bbp:dataSpace. On the other hand, bbp:Circuit_2 is not valid because it has not a value for bbp:dataSpace property.\nProperty Value Type Constraints\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:dataSpace\",\n \"name\" : \"Data Space\",\n \"description\" : \"Data Space.\",\n \"minCount\":\"1\"\n },\n {\n \"path\" : \"bbp:brainRegion\",\n \"name\" : \"Brain region\",\n \"description\" : \"Brain region.\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\",\n \"node\": \"circuitshape:LabeledOntologyTermShape\"\n },\n {\n \"path\" : \"schema:name\",\n \"name\" : \"Name\",\n \"description\" : \"Circuit name\",\n \"datatype\": \"xsd:string\",\n \"minCount\":\"1\",\n \"maxCount\":\"1\"\n }\n ]\n },\n {\n \"@id\" : \"circuitshape:LabeledOntologyTermShape\",\n \"@type\" : \"sh:NodeShape\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"rdfs:label\",\n \"name\" : \"label\",\n \"description\" : \"Human readable label\",\n \"datatype\": \"xsd:string\",\n \"maxCount\" : 1,\n \"minCount\" : 1\n\n }\n }\n ]\n}\nThe type of a property value can be restricted. In the schema example, all instances of bbp:circuit should have exactly one name which should be of type string. How to express such type restriction in a shacl schema ?\nPrimitive type as property value\nA property value can be of a primitive type: string, integer, double, anyURI, … and datatype key is used to define such primitive expected types as shown in the shacl schema example. The namespace of all primitive types is xsd and for a complete list of those types please check here.\nProperty values are not always primitive and two other typical situations may occurs.\nReference as property value\nThe type of a property value can be restricted to be an instance of a specific class. For example, it may be useful to enforce all values of the bbp:morphology property of a given circuit to be of type bbp:Morphology. To express this type of constraint the key class is used as shown in the schema example. The ability to constraint types is important to ensure the quality and reliability of the data being submitted into the Nexus platform and SHACL allows to do that without writing a single line of validation code.\nNode as property value\nSometimes it may be useful to enforce that a property value has a particular shape instead of being of a specific type. For example, we may want to enforce all brain region values of a all circuits (instances of bbp:Circuit) to have at least an IRI as identifier (“nodeKind”: “sh:IRI”) and a label as human readable description. The key node is used to express a shape constraint.","title":"Property Constraints"},{"location":"/docs/shacl-tutorial/overview/constraints.html#qualified-cardinality","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"3\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:morphology\",\n \"qualifiedValueShape\": {\n \"class\" : \"bbp:RawMorphology\"\n },\n \"qualifiedValueShapesDisjoint\": true,\n \"qualifiedMinCount\":1,\n \"qualifiedMaxCount\":1\n },\n {\n \"path\" : \"bbp:morphology\",\n \"qualifiedValueShape\": {\n \"class\" : \"bbp:SynthesizedMorphology\"\n },\n \"qualifiedValueShapesDisjoint\": true,\n \"qualifiedMinCount\":1\n }\n ]\n }\n ]\n}\nCardinality constraints can be more complex than what is presented in the constraints section above. A complex cardinality use case can be expressed in the following way : *a bbp:Circuit instance should be linked with exactly 3 Morphologies (instances of bbp:Morphology) *exactly one of them should be a raw morphology (an instance of bbp:RawMorphology) *at least one of them should be synthesized morphology (an instance of bbp:SynthesizedMorphology) *and a bbp:Circuit instance can’t be at the same time of type bbp:RawMorphology and bbp:SynthesizedMorphology\nThe schema example shows how to implement the above constraints using the following keys:\nkey Description qualifiedValueShape Mandatory. The shape that the specified (through qualifiedMinCount and qualifiedMaxCount) number of nodes should be consistent with. qualifiedMinCount Mandatory. The minimum number of nodes that should be consistent with the shape in qualifiedValueShape qualifiedMaxCount Mandatory. The maximum number of nodes that should be consistent with the shape in qualifiedValueShape qualifiedValueShapesDisjoint Optional. If true then the values conform to the current property shape must not conform to the siblings property shapes","title":"Qualified Cardinality"},{"location":"/docs/shacl-tutorial/overview/constraints.html#combining-shapes","text":"Until now we’ve described how to define a shape that targets different nodes using different selectors and enforcing different type of constraints. But designing real life schemas is complex and often required reuse of already defined ones. Two use cases can occur when it comes to reuse SHACL schemas:\nreuse a shape by combining it with other shapes using boolean operators specialization mechanism between shapes","title":"Combining shapes"},{"location":"/docs/shacl-tutorial/overview/constraints.html#logical-combination-of-shapes","text":"A node shape definition for all instances of bbp:Entity\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"this:EntityShape\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Entity\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [{\n \"path\" : \"schema:name\",\n \"name\" : \"Name\",\n \"description\" : \"Entity name\",\n \"or\":[\n {\n \"datatype\": \"xsd:string\"\n },\n {\n \"datatype\": \"xsd:integer\"\n }\n ]\n },{\n \"path\" : \"schema:description\",\n \"name\" : \"Description\",\n \"description\" : \"The entity description\",\n \"datatype\" : \"xsd:string\"\n }\n ]\n }\n ]\n}\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"@type\": \"owl:Ontology\",\n \"imports\" : [ \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\"],\n \"shapes\" : [ {\n \"@id\" : \"this:Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"and\":[{\n \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\"\n },\n {\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n }\n ]\n }\n ]\n }\n ]\n}\nShapes can be combined using the following boolean operators:\nkey Description and The data has to be valid with respect to all combined shapes or The data has to be valid with respect to at least one shape xone The data has to be valid with respect to only one shape not The data should not be valid with respect to the given shape(s)\nIn the previous schema (identified by {endpoint}/schemas/bbp/simulation/circuit/v1.0.0/), the property shape related to schema:name property can be externalized in a schema ({endpoint}/schemas/bbp/core/entity/v1.0.0/) belonging to the “bbp” organization, “core” domain and named “entity” as shown in the right tab. Now let reuse (see in the right) the entity schema since a bbp:Circuit is a bbp:Entity as well. Basically, the schema is expressing that a bbp:Circuit instance should be consistent with respect to the schema for bbp:Entity (external one) and the one for bbp:Circuit (local one).\nNote the use of the **imports** key. It tells the shacl validator where to find the shapes that are referenced in the local schema: \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\" for example. Only published schemas can be imported.\nThe or, xone and not operators can be used in the same way as the and one. The example shows how to logically combined two node shapes. Property shapes can be combined as well as shown in the shape this:EntityShape where the property schema:name van be of type string of integer.\nAll shapes that are listed in the shapes array are by default considered combined in conjunctive way (and operator).","title":"Logical combination of shapes"},{"location":"/docs/shacl-tutorial/overview/constraints.html#shape-specialization","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"@type\": \"owl:Ontology\",\n \"imports\" : [ \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\"],\n \"shapes\" : [ {\n \"@id\" : \"this:Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"and\":[{\n \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\"\n },\n {\n \"property\" : [\n {\n \"path\" : \"schema:description\",\n \"minCount\" : 1\n \"maxCount\" : 1\n },\n {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n }\n ]\n }\n ]\n }\n ]\n}\nIn the previous section, the circuit schema example already introduces a bit the way a shape can be specialized. Indeed combining shapes using the and boolean operator conveys a sense of extension. But the specialization can go further than just adding more constraints on top of a reused schema. The this:Circuit can further constraint the use of the schema:description property in all bbp:Circuit instances by setting a minimal and a mawimal cardinality. All bbp:Circuit instances must have exactly one value for the property schema:description whereas it’s not mandatory for other bbp:Entity instances.\nNote that only the and boolean operator can be used for shape specialization.","title":"Shape specialization"},{"location":"/docs/shacl-tutorial/overview/constraints.html#frequent-shacl-validation-errors","text":"WIP","title":"Frequent SHACL validation errors"},{"location":"/docs/shacl-tutorial/index.html","text":"","title":"SHACL Overview"},{"location":"/docs/shacl-tutorial/index.html#shacl-overview","text":"This document presents an example-driven tutorial on how to build a linked data model for a given domain of application using:\nW3C SHACL recommendation as a data modeling language Blue Brain Nexus as a data management and publishing platform.\nThroughout this document, a simple example of a domain of interest is developed. The example, illustrate different linked data modeling challenges and requirements and demonstrate how they can be met by leveraginb Knowledge about linked data and the Nexus platform REST API is recommended even though not mandatory. You can view the following excellent video on Linked data on youtube.\nNote This tutorial makes use of a SHACL Playground to tests that data conform to schemas. The Nexus explorer will be used to view and navigate the built linked data models.","title":"SHACL Overview"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_validation-flow.html","text":"","title":"What is SHACL ?"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_validation-flow.html#what-is-shacl-","text":"","title":"What is SHACL ?"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_validation-flow.html#shape","text":"How a shape works? SHACL Validation flow\nGiven an input data graph (a json-ld document):\nNode to be focused on for validation are selected using targets: list the different targets Filters can be used to eliminate some focused nodes Validate focused nodes using constraints","title":"Shape"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html","text":"","title":"Node shapes identifiers"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#node-shapes-identifiers","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/CircuitShape\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"property\":[{\n \"@id\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/ConnectomeShape\",\n \"path\": \"bbpprodprop:connectome\"\n \"name\": \"Connectome\",\n \"description\": \"Connectome\",\n \"datatype\": \"xsd:string\",\n \"maxCount\": 1,\n \"minCount\": 0\n }\n ]\n }\n ]\n}\nIt is strongly recommended to provide identifiers (value for @id) for the node shapes (things of type sh:NodeShape) so that they can be reused and discovered through the Nexus Rest API.\nBoth node shapes and property shapes can have identifiers.\nA property shape needs to have an identifier only if there is a need to reuse it.","title":"Node shapes identifiers"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#nexus-schema-annotations","text":"Schemas are often designed with reuse in mind. Good annotations is key in order to enable schema discoverability and reuse. The following list presents a set of recommended annotations that one can use to describe a schema:\n…WIP","title":"Nexus schema annotations"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#shape-annotations","text":"","title":"SHAPE annotations"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#node-shape-annotations","text":"Node shapes are shapes with type sh:NodeShape. It is recommended that a node shape is annotated with the following properties:\nKey Description label A human readable label for the node shape. This property is a short form for rdfs:label. comment A human readable description of the node shape.This property is a short form for rdfs:comment.","title":"Node shape annotations"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#property-shape-annotations","text":"Property shapes are shapes with type sh:PropertyShape. It is recommended that a property shape is annotated with the following properties:\nKey Description name A human readable name for the shape. The name is usually displayed when a form is generated from the shape description A human readable description of the shape. Also used in form generation\nAnnotation properties are not taken into accoiunt during validation.","title":"Property shape annotations"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#shape-keys-ordering","text":"To improve the SHACL schema readability, it is recommended to adopt the following ordering when defining:\na Node Shape\nOrder Key Description 1 @id Always start with the node shape identifier if any 2 @type The node shape type 3 label A human readable description of the node shape. 4 comment A description of the node shape. 5 target(Class-Node-ObjectsOf-SubjectsOf) The node shape target 6 nodeKind The node shape node kind 7 property The node shape properties\na Property Shape\nOrder Key Description 1 @id Always start with the property shape identifier if any. Most of the time, there is no need to have an identifier for a property shape 2 @type The property shape type. Most of the time, there is no need to add a type to a property shape 3 path The property targeted by the property shape. 4 name A human readable name for the property shape. 5 description A human readable description of the property shape. 6 nodeKind The property shape node kind. Cannot be present when datatype is present. 7 class or datatype These two keys are mutually exclusive. THus they can occurs in the same property shape at the same time. Every value of the targeted property (defined in path) should have the value of class or datatype as type 8 node Always has a node shape as value. Every value of the targeted property (defined in path) should conform to the referenced node shape. 9 minCount or maxCount Cardinality constraints.","title":"SHAPE keys ordering"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#naming-conventions","text":"","title":"Naming conventions"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#class-name-as-single-noun","text":"In schemas, classes (values of targetClass, of @type) are named using camel case notation:\nclass name should start with a capital letter class name should be singular no space is allowed good examples: “bbp:Circuit”, bbp:RawMorphology bad examples: “bbp:Circuits”, “bbp:circuit” but also “bbp:Raw_Morphology”","title":"Class name as single noun"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#instance-name-as-single-noun","text":"Instances naming follows the same conventions as class naming. In a schemas, instances are things that have a type (@type): mainly the shapes (node and property shapes).","title":"Instance name as single noun"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_nexus-schemas.html#property-name-as-verb-sense-or-single-noun","text":"In schemas, properties (mainly values of sh:path) are named using the following convention:\nproperty name should start with lower case and be capitalized thereafter property name should be singular no space is allowed good example: “bbp:morphology”, “bbp:hasFileExtension” or “bbp:fileExtension” bad examples: “bbp:morphologies” but also “bbp:segment_index”","title":"Property name as verb sense or single noun"},{"location":"/docs/data-models/literature/neuronclassification.html","text":"","title":"Literature Annotation"},{"location":"/docs/data-models/literature/neuronclassification.html#literature-annotation","text":"","title":"Literature Annotation"},{"location":"/docs/data-models/literature/neuronclassification.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/literature/neuronclassification.html#description","text":"Axon projection M-type\nSteps: - Get all cell types","title":"Description"},{"location":"/docs/data-models/literature/neuronclassification.html#competency-questions","text":"","title":"Competency questions"},{"location":"/docs/data-models/literature/neuronclassification.html#abstract-data-model","text":"","title":"Abstract Data model"},{"location":"/docs/shacl-tutorial/_convention.html","text":"","title":"Document convention"},{"location":"/docs/shacl-tutorial/_convention.html#document-convention","text":"The @context will be omitted in the following tutorials unless it’s important.","title":"Document convention"},{"location":"/docs/shacl-tutorial/overview/validation-flow.html","text":"","title":"Validation flow"},{"location":"/docs/shacl-tutorial/overview/validation-flow.html#validation-flow","text":"Data validation using a SHACL processor involves two type of resources:\na shape defining the constraints the data should conform to: the shape is called shapes graph in the W3C SHACL recommendation. the data to be validated against the shape: called data graph in the W3C SHACL recommendation\nGiven a shape and a data as inputs, a SHACL processor starts by selecting what part of the data to focus on and then validate whether that part conforms to the shape graph or not.","title":"Validation flow"},{"location":"/docs/shacl-tutorial/overview/validation-flow.html#data-selection","text":"A shape can specify the nodes it will validate within a data graph by using one or many target declarations. A shape can target:\na specific node nodes of a given type nodes that are subject of a given property nodes that are object of a given property","title":"Data selection"},{"location":"/docs/shacl-tutorial/overview/validation-flow.html#data-validation","text":"When focused nodes to validate against a shape are identified then the validation can occurs. A SHACL processor will check if a node conform to the constraints defined in a shape that selects it. A validation report is produced at the end.\nShwo example.","title":"Data validation"},{"location":"/docs/index.html","text":"","title":"Neuroshapes"},{"location":"/docs/index.html#neuroshapes","text":"","title":"Neuroshapes"},{"location":"/docs/index.html#why-neuroshapes-","text":"The goal of Neuroshapes is the development of open, use case driven and shared validatable data models (schemas, vocabularies) to enable the FAIR principles (Findable, Accessible, Interoperable and Reusable) for basic, computational and clinical neuroscience (meta)data. The data models developed thus far entities for electrophysiology, neuron morphology, brain atlases, in vitro electrophysiology and computational modeling. Future developments could include brain imaging, transcriptomic and clinical form data, as determined by community interests.\nNote All data models presented in this documentation are still drafts. Potential changes can be discussed on Github or on Gitter","title":"Why Neuroshapes ?"},{"location":"/docs/index.html#neuroshapes-goals","text":"the use of standard semantic markups and linked data principles as ways to structure metadata and related data: the W3C RDF format is leveraged, specifically its developer-friendly JSON-LD serialization. The adoption of linked data principles and JSON-LD will ease federated access and discoverability of distributed neuroscience (meta)data over the web. the use of the W3C SHACL (Shapes Constraint Language) recommendation as a rich metadata schema language which is formal and expressive; interoperable; machine-readable; and domain-agnostic. With SHACL, (meta)data quality can be enforced based on schemas and vocabularies (easily discoverable and searchable) rather than being fully encoded in procedural codes. SHACL also provides key interoperability capabilities to ensure the evolution of standard data models and data longevity. It allows to incrementally build standard data models in terms of semantics and sophistication. the reuse of existing schemas and semantic markups (like schema.org ) and existing ontologies and controlled vocabularies (including NIFSTD - NIF Standard Ontologies) the use of the W3C PROV-O recommendation as a format to record (meta)data provenance: a SHACL version of the W3C PROV-O is created.","title":"Neuroshapes Goals"},{"location":"/docs/index.html#get-involved","text":"Join the INCF Special Interest Group on Neuroshapes Read the How to contribute section","title":"Get involved"},{"location":"/docs/gettingstarted/index.html","text":"","title":"Getting Started"},{"location":"/docs/gettingstarted/index.html#getting-started","text":"","title":"Getting Started"},{"location":"/docs/gettingstarted/overview.html","text":"","title":"Overview"},{"location":"/docs/gettingstarted/overview.html#overview","text":"A draft for a standardized description of data provenance for the following domains:\nData models Brain Atlas Electrophysiology Morphology\nNote All data models presented in this documentation are still drafts. Potential changes can be discussed on Github or on Gitter","title":"Overview"},{"location":"/docs/gettingstarted/download.html","text":"","title":"Download"},{"location":"/docs/gettingstarted/download.html#download","text":"Neuroshapes schemas are tested using a shacl workbench which is a SBT plugin that helps in the development of SHACL schemas in JSON-LD format. Please follow these steps to run the tests and download the schemas:\nInstall sbt Clone the INCF/neuroshapes repository and run the tests\n# Go to home\ncd ~\n\n# Clone the repository\ngit clone https://github.com/INCF/neuroshapes.git\n\ncd neuroshapes\n\n# Run 'sbt'\nsbt\n\n# Run 'test'\ntest\n\n# Export all the locally defined schemas to the dir /tmp/my-schemas using as base uri \nexportSchemas http://localhost:8080/v0 /tmp/my-schemas\n\n# Schemas can be defined in modules that are imported by local modules. The collectResources command can be run to collect all schemas and contexts defined in this project classpath\n\n## Collect schemas\ncollectResources http://localhost:8080/v1 /tmp/my-schemas schemas\n\n## Collect everything defined\ncollectResources http://localhost:8080/v1 /tmp/my-schemas all","title":"Download"},{"location":"/docs/gettingstarted/contribution.html","text":"","title":"How to contribute"},{"location":"/docs/gettingstarted/contribution.html#how-to-contribute","text":"We would love for you to contribute to the Neuroshapes familly of data models and help make them even better than they are now! As a contributor, find in the next sections the guidelines we would like you to follow.","title":"How to contribute"},{"location":"/docs/gettingstarted/contribution.html#got-a-question-or-a-problem-","text":"Please do not hesitate to open an issue here and join the INCF neuroshapes SIG at INCF Special Interest Group on Neuroshapes.","title":"Got a Question or a Problem?"},{"location":"/docs/gettingstarted/contribution.html#found-a-bug-","text":"If you find a bug in the source code of any tools, in any schema or vocabulary in this repository, you can help us fix it by submitting an issue to our GitHub Repository. Even better, you can submit a Pull Request with a fix.","title":"Found a Bug?"},{"location":"/docs/gettingstarted/contribution.html#missing-a-feature-or-a-data-model-","text":"You can request them by submitting an issue to our GitHub Repository. If you would like to implement a new feature or propose a new data model specification, please submit an issue with a proposal for your work first, to be sure it can be implemented and most importantly, to trigger discussions and enable collaborations with interested people. Please consider what kind of change it is:\nFor a Data Model Specification Proposal or Extension, first open an issue and outline your proposal so that it can be discussed. Data examples implementing/illustrating an existing Data Model can be directly submitted as a Pull Request. For example different atlas releases conformant to the atlas registration prov pattern can be submitted. For a Major Feature related to the tools and scripts made available in this repository, first open an issue and outline your proposal so that it can be discussed. This will also allow us to better coordinate our efforts, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project. Small Features can be crafted and directly submitted as a Pull Request.","title":"Missing a Feature or a data model?"},{"location":"/docs/gettingstarted/contribution.html#submission-guidelines","text":"","title":"Submission Guidelines"},{"location":"/docs/gettingstarted/contribution.html#submitting-an-issue","text":"Before you submit an issue, please search the issue tracker, maybe an issue for your problem already exists and the discussion might inform you of workarounds readily available. We want to fix all the issues as soon as possible, but before fixing a bug we need to reproduce and confirm it. In order to reproduce bugs we will need as much information as possible, and preferably be in touch with you to gather information.","title":"Submitting an Issue"},{"location":"/docs/gettingstarted/contribution.html#submitting-a-data-model-specification","text":"Before you submit your proposal consider the following guidelines:\nPlease join the INCF Special Interest Group (SIG) on Neuroshapes before sending pull requests. Proposals are managed and reviewed by members of that INCF SIG. Open an issue and outline your proposal so that it can be discussed.","title":"Submitting a Data Model Specification"},{"location":"/docs/gettingstarted/contribution.html#submitting-a-pull-request-pr-","text":"Before you submit your Pull Request (PR) consider the following guidelines:\nPlease join the INCF SIG on Neuroshapes before sending Pull requests. Proposals are managed and reviewed by members of that INCF SIG. Clone the Neuroshapes github repository:\n# Go to home\n cd ~\n \n # Clone the repository\n git clone https://github.com/INCF/neuroshapes.git\n \n cd neuroshapes\nMake your changes in a new git branch: shell git checkout -b my-fix-branch master Create your patch, including appropriate test cases. Run the full test suite, and ensure that all tests pass. # Run 'sbt'\nsbt\n\n# Run 'test'\ntest\n\n# Exit\nexit\n\n Commit your changes using a descriptive commit message. shell git commit -a Note: the optional commit -a command line option will automatically “add” and “rm” edited files. Push your branch to GitHub: git push origin my-fix-branch\n In GitHub, send a pull request to the master branch. If we suggest changes then: Make the required updates. Re-run the test suites to ensure tests are still passing. Rebase your branch and force push to your GitHub repository (this will update your Pull Request): git rebase master -i\ngit push -f\n That’s it! Thank you for your contribution! After your pull request is mergedAfter your pull request is merged, you can safely delete your branch and pull the changes from the main (upstream) repository: Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows: git push origin --delete my-fix-branch\n Check out the master branch: git checkout master -f\n Delete the local branch: git branch -D my-fix-branch\n Update your master with the latest upstream version: git pull --ff upstream master","title":"Submitting a Pull Request (PR)"},{"location":"/docs/gettingstarted/contribution.html#join-the-incf-neuroshape-sig","text":"Join the INCF Special Interest Group on Neuroshapes.","title":"Join the INCF Neuroshape SIG"},{"location":"/docs/datamodeling/index.html","text":"","title":"Modeling Your Data"},{"location":"/docs/datamodeling/index.html#modeling-your-data","text":"TBD","title":"Modeling Your Data"},{"location":"/docs/shacl-tutorial/overview/index.html","text":"","title":"SHACL In a Nutshell"},{"location":"/docs/shacl-tutorial/overview/index.html#shacl-in-a-nutshell","text":"Please find below some resources as well as useful links for building data models involving SHACL shapes:\nThe W3C SHACL specification Useful resources when learning SHACL SHACL reference book, tutorials and playground http://www.validatingrdf.com/ SHACL playground: http://shacl.org/playground/ Topquadrant SHACL tutorial Useful resources when learning JSON-LD https://json-ld.org Json-ld API best practicies Ontology/SHACL editor TopBraid Composer Free Edition SHACL validator SHACLEX: scala based pySHACL: python based TopQuadrant/shacl: JAVA based","title":"SHACL In a Nutshell"},{"location":"/docs/data-models/index.html","text":"","title":"Data Model Specifications"},{"location":"/docs/data-models/index.html#data-model-specifications","text":"","title":"Data Model Specifications"},{"location":"/docs/data-models/index.html#overview","text":"This section describes key scientific and technical activities and agents involved in the generation of various neuroscience data types (basic, computational and clinical neuroscience data). For each data types, the generation context is described by mean of a data provenance pattern which is implemented as a set of W3C SHACL based validatable schemas.\nBrain Atlas Electrophysiology Morphology","title":"Overview"},{"location":"/docs/data-models/brainatlas/brain-atlas.html","text":"","title":"Brain Atlas"},{"location":"/docs/data-models/brainatlas/brain-atlas.html#brain-atlas","text":"In this section we describe data models that represent the use of brain atlases.","title":"Brain Atlas"},{"location":"/docs/data-models/brainatlas/brain-atlas.html#use-cases","text":"List of use cases:\nRegistering a brain atlas Registering a whole brain morphology into an atlas","title":"Use cases"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html","text":"","title":"Registering a Brain Atlas"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#registering-a-brain-atlas","text":"","title":"Registering a Brain Atlas"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#description","text":"This specification describes the process of register a brain atlas. The process starts with a subject collection which are imaged and processed to generate 3 derived entities: a template image data, a parcellation image data, as well as brain parcellation labels. The first 2 entities are further transformed into volumetric representation, from which an atlas spatial reference system is derived. The parcellation labels are converted into ontology. The final template volume, parcellation volume, parcellation ontology as well as the atlas spatial reference system are used to form an atlas release.","title":"Description"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#supported-data-queries","text":"From a specific version of a brain atlas:\nGet the brain parcellation dataset Get the brain parcellation labels dataset Get the image stack datasets Get the coordinate system of the atlas spatial reference system","title":"Supported Data Queries"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#data-provenance-pattern","text":"","title":"Data Provenance pattern"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#schemas","text":"","title":"Schemas"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#entities","text":"The different entity types involved are described below.\nType Description SubjectCollection A collection of subject to be used in the experiment TemplateImageData Template image data acquired and processed from the subject collection ParcellationImageData Parcellation image data generated from the template image data ParcellationLabel Parcellation labels correspond to the annotations in the parcellation image TemplateVolume Template volume generated from the template image data ParcellationVolume Parcellation volume generated from the parcellation image data ParcellationOntology Parcellation ontology converted from the parcellation label AtlasSpatialReferenceSystem The spatial coordinate system of the atlas space AtlasRelease An atlas release comprises template volume, parcellation volume, parcellation ontology as well as the atlas spatial reference system Protocol Protocol that describes the method used in the design and execution of the experiment","title":"Entities"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#activities","text":"Type Description Atlas Construction Process to construct a brain atlas Template Reconstruction Reconstruct the template image data into volumetric representation Parcellation Reconstruction Reconstruct the parcellation image data into volumetric representation Ontology Conversion Convert the parcellation label into ontological representation","title":"Activities"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#agents","text":"Type Description Person Person associated with an activity SoftwareAgent Software associated with an activity Organization Organization associated with an activity","title":"Agents"},{"location":"/docs/data-models/brainatlas/registering-brain-atlas.html#contributors","text":"Huanxiang Lu Anna-Kristin Kaufmann Silvia Jimenez Sy Mohameth Francois Samuel Kerrien Sean Hill","title":"Contributors"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html","text":"","title":"Registering a Whole Brain Morphology in an Atlas"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#registering-a-whole-brain-morphology-in-an-atlas","text":"","title":"Registering a Whole Brain Morphology in an Atlas"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#description","text":"This specification describes the process of register a whole brain morphology into an atlas. The process starts with reconstruction the whole brain morphologies from image stack. The image stack is used to register to the reference atlas, resulting in a transformation. This transformation is then used to transform the reconstructed whole brain cell into the reference atlas space.","title":"Description"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#supported-data-queries","text":"Get the whole brain morphology from a given atlas spatial reference system. Get the whole brain morphologies derived from a image stack","title":"Supported Data Queries"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#data-provenance-pattern","text":"","title":"Data Provenance pattern"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#schemas","text":"","title":"Schemas"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#entities","text":"The different entity types involved are described below.\nType Description Subject Subject that was used in the experiment TemplateVolume Template volume generated from the template image data AtlasSpatialReferenceSystem The spatial coordinate system of the atlas space ImageStack Image stack obtained from the brain tissue of the subject ReconstructedCell Reconstructed cell Transform A linear or non-linear transform Protocol Protocol that describes the method used in the design and execution of the experiment","title":"Entities"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#activities","text":"Type Description BrainImaging Technique used to obtain an image stack of the brain tissue containing the cells for reconstruction ReconstructionFromImage Technique used to reconstruct the stained cell Transformation Transform a geometric object","title":"Activities"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#agents","text":"Type Description Person Person associated with an activity SoftwareAgent Software associated with an activity Organization Organization associated with an activity","title":"Agents"},{"location":"/docs/data-models/brainatlas/registering-whole-brain-morphology.html#contributors","text":"Huanxiang Lu Anna-Kristin Kaufmann Silvia Jimenez Sy Mohameth Francois Samuel Kerrien Sean Hill","title":"Contributors"},{"location":"/docs/data-models/electrophysiology/electrophysiology.html","text":"","title":"Electrophysiology"},{"location":"/docs/data-models/electrophysiology/electrophysiology.html#electrophysiology","text":"In Neuroscience, electrophysiology refers to the study of the electrical activity of neurons, e.g. by measuring action potential activity. In this section, we describe data models that represent the generation context of the following neuroscience data types:","title":"Electrophysiology"},{"location":"/docs/data-models/electrophysiology/electrophysiology.html#intracellular-recording","text":"Note In Vitro Whole Cell Patch Clamp Recording In Vitro IntraCellular Sharp Electrode Recording","title":"Intracellular Recording"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html","text":"","title":"In Vitro Whole Cell Patch Clamp Recording"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#in-vitro-whole-cell-patch-clamp-recording","text":"","title":"In Vitro Whole Cell Patch Clamp Recording"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#description","text":"This specification describes the metadata collected for in vitro intracellular electrophysiology recordings using the whole cell patch clamp configuration. Whole cell patch clamp is a type of electrophysiological recording used to measure ionic currents over the membrane of an entire cell. Suction is applied to rupture the cell membrane which provides access to the intracellular space of the patched cell. Metadata is collected on the subject used in the experiment, the slice, the patched cell which was recorded as well as the recording traces and protocols. Additionally, metadata for the brain slicing, the whole cell patch clamp and the stimulus (including protocols and agents) involved in the generation of the recording traces are captured.","title":"Description"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#supported-data-queries","text":"The following points describe an example subset of questions supported by the data provenance pattern:\nRetrieve all recording traces generated from rat somatosensory cortex using selected stimuli. Retrieve recording traces by recording day and experimenter. Retrieve all response traces from a specific patched cell. Get the holding potential for an individual recording trace.","title":"Supported Data Queries"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#data-provenance-pattern","text":"","title":"Data Provenance pattern"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#schemas","text":"","title":"Schemas"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#entities","text":"The different entity types involved in the experiment are listed below.\nType Description Subject Subject that was used in the experiment Slice Brain slice obtained from the subject PatchedSlice Brain slice containing patched cells PatchedCellCollection Collection of patched cells in a single slice (e.g. for multi-patch recordings) PatchedCell Cell that was patched in the slice Trace Individual recording trace of the patched cell (stimulation/input and response/output trace) Protocol Protocol that describes the method used in the design and execution of the experiment","title":"Entities"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#activities","text":"The different activity types involved in the experiment are listed below.\nType Description BrainSlicing Technique used to obtain a brain slice for patching WholeCellPatchClamp Technique used to study electrical activity of individual living cells StimulusExperiment Technique used to obtain the electrical signature of cells through injection of a defined current pattern","title":"Activities"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#agents","text":"The different agent types involved in the experiment are listed below.\nType Description Person Person associated with an activity SoftwareAgent Software associated with an activity Organization Organization associated with an activity","title":"Agents"},{"location":"/docs/data-models/electrophysiology/wholecellpatchclamp-recording.html#contributors","text":"Anna-Kristin Kaufmann Huanxiang Lu Silvia Jimenez Rodrigo Perin Sy Mohameth Francois Samuel Kerrien Sean Hill","title":"Contributors"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html","text":"","title":"In Vitro IntraCellular Sharp Electrode Recording"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#in-vitro-intracellular-sharp-electrode-recording","text":"","title":"In Vitro IntraCellular Sharp Electrode Recording"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#description","text":"This specification describes the metadata collected for in vitro intracellular electrophysiology recordings using intracellular sharp electrodes configuration. Metadata is collected on the subject used in the experiment, the slice, the cell which was recorded as well as the recording traces and protocols. Additionally, metadata for the brain slicing, the intracellular sharp electrodes and the stimulus (including protocols and agents) involved in the generation of the recording traces are captured.","title":"Description"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#supported-data-queries","text":"The following points describe an example subset of questions supported by the data provenance pattern:\nRetrieve all recording traces generated from rat somatosensory cortex using selected stimuli. Retrieve recording traces by recording day and experimenter. Retrieve all response traces from a specific recorded cell.","title":"Supported Data Queries"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#data-provenance-pattern","text":"","title":"Data Provenance pattern"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#schemas","text":"","title":"Schemas"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#entities","text":"The different entity types involved in the experiment are listed below.\nType Description Subject Subject that was used in the experiment Slice Brain slice obtained from the subject IntraCellularSharpElectrodeRecordedSlice Brain slice containing recorded cells IntraSharpRecordedCellCollection Collection of recorded cells in a single slice IntraCellularSharpElectrodeRecordedCell Cell that was recorded in the slice Trace Individual recording trace of the cell (stimulation/input and response/output trace) Protocol Protocol that describes the method used in the design and execution of the experiment","title":"Entities"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#activities","text":"The different activity types involved in the experiment are listed below.\nType Description BrainSlicing Technique used to obtain a brain slice IntraCellularSharpElectrode Technique used to study electrical activity of individual living cells StimulusExperiment Technique used to obtain the electrical signature of cells through injection of a defined current pattern","title":"Activities"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#agents","text":"The different agent types involved in the experiment are listed below.\nType Description Person Person associated with an activity SoftwareAgent Software associated with an activity Organization Organization associated with an activity","title":"Agents"},{"location":"/docs/data-models/electrophysiology/intracellularsharpelectrode-recording.html#contributors","text":"Andrew Davison Anna-Kristin Kaufmann Huanxiang Lu Silvia Jimenez Sy Mohameth Francois Samuel Kerrien Sean Hill","title":"Contributors"},{"location":"/docs/data-models/morphology/morphology.html","text":"","title":"Neuron Morphology"},{"location":"/docs/data-models/morphology/morphology.html#neuron-morphology","text":"Note In this section we describe data models that represent the generation context of the following neuron morphology data types: In Vitro Slice Neuron Morphology Reconstruction Whole Brain Neuron Morphology Reconstruction","title":"Neuron Morphology"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html","text":"","title":"In Vitro Slice Neuron Morphology Reconstruction"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#in-vitro-slice-neuron-morphology-reconstruction","text":"","title":"In Vitro Slice Neuron Morphology Reconstruction"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#description","text":"This specification describes metadata collected for morphology reconstructions from brain slices. Reconstruction of a neuron morphology from slice typically follows the injection of a dye during a whole cell patch clamp recording. Some of the activities and entities shown here are hence shared with the in vitro whole cell patch clamp recording. Metadata is collected on the subject used in the experiment, the slice containing the cell, the labeled cell and the reconstructed neuron morphology. The dye-filled neuron is most commonly visualized using a histological technique following the fixation of the brain tissue. The stained cells are annotated and then reconstructed. Metadata from all these procedures is captured as well as the protocols used and the persons, software and organizations involved in each of the steps.","title":"Description"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#supported-data-queries","text":"The following points describe an example subset of questions supported by the data provenance pattern:\nRetrieve morphology reconstructions from a given brain region. Retrieve pyramidal cell reconstructions. Retrieve morphology reconstructions from a specific experimenter. Retrieve morphology reconstructions from a subject of a given age and sex. Retrieve morphology reconstructions which were reconstructed in a given year","title":"Supported Data Queries"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#data-provenance-pattern","text":"","title":"Data Provenance pattern"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#schemas","text":"","title":"Schemas"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#entities","text":"The different entity types involved in the experiment are listed below.\nType Description Subject Subject that was used in the experiment Slice Brain slice obtained from the subject PatchedSlice Brain slice containing patched cells PatchedCellCollection Collection of patched cells in a single slice (e.g. for multi-patch recordings) PatchedCell Cell that was patched in the slice FixedStainedSlice Brain slice after fixation and staining AnnotatedSlice Brain slice containing the identified and annotated stained cells LabeledCellCollection Collection of labeled cells in a single slice LabeledCell Cell that was labeled in the slice ReconstructedCell Reconstructed cell Protocol Protocol that describes the method used in the design and execution of the experiment","title":"Entities"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#activities","text":"The different activity types involved in the experiment are listed below.\nType Description BrainSlicing Technique used to obtain a brain slice for patching WholeCellPatchClamp Technique used to study electrical activity of individual living cells FixationStainingMounting Technique used to fix and stain the slice AcquisitionAnnotation Technique used to acquire an image of the slice and annotate the stained cells Reconstruction Technique used to reconstruct the stained cell","title":"Activities"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#agents","text":"The different agent types involved in the experiment are listed below.\nType Description Person Person associated with an activity SoftwareAgent Software associated with an activity Organization Organization associated with an activity","title":"Agents"},{"location":"/docs/data-models/morphology/morphology-reconstruction.html#contributors","text":"Anna-Kristin Kaufmann Huanxiang Lu Silvia Jimenez Rodrigo Perin Sy Mohameth Francois Samuel Kerrien Sean Hill","title":"Contributors"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html","text":"","title":"Whole Brain Neuron Morphology Reconstruction"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#whole-brain-neuron-morphology-reconstruction","text":"","title":"Whole Brain Neuron Morphology Reconstruction"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#description","text":"This specification describes metadata collected for whole brain morphology reconstructions from a continuous whole brain image stack. Reconstruction of a neuron morphology from an image stack is typically enabled through sparse neuronal labeling following e.g. viral delivery of a fluorescent protein. Metadata is collected on the subject used in the experiment, the image stack containing the labeled cells and the reconstructed neuron morphology. Additionally, metadata for the brain imaging and the reconstruction from image (including protocols and agents) are captured.","title":"Description"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#supported-data-queries","text":"The following points describe an example subset of questions supported by the data provenance pattern:\nRetrieve morphology reconstructions from a given brain region. Retrieve pyramidal cell reconstructions. Retrieve morphology reconstructions projecting to a given brain region. Retrieve morphology reconstructions from a subject of a given age and sex. Retrieve morphology reconstructions which were reconstructed by a specific person.","title":"Supported Data Queries"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#data-provenance-pattern","text":"","title":"Data Provenance pattern"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#schemas","text":"","title":"Schemas"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#entities","text":"The different entity types involved in the experiment are listed below.\nType Description Subject Subject that was used in the experiment ImageStack Image stack obtained from the brain tissue of the subject ReconstructedCell Reconstructed cell Protocol Protocol that describes the method used in the design and execution of the experiment","title":"Entities"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#activities","text":"The different activity types involved in the experiment are listed below.\nType Description BrainImaging Technique used to obtain an image stack of the brain tissue containing the cells for reconstruction ReconstructionFromImage Technique used to reconstruct the stained cell","title":"Activities"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#agents","text":"The different agent types involved in the experiment are listed below.\nType Description Person Person associated with an activity SoftwareAgent Software associated with an activity Organization Organization associated with an activity","title":"Agents"},{"location":"/docs/data-models/morphology/whole-brain-neuron-morphology-reconstruction.html#contributors","text":"Anna-Kristin Kaufmann Huanxiang Lu Silvia Jimenez Rodrigo Perin Sy Mohameth Francois Samuel Kerrien Sean Hill","title":"Contributors"},{"location":"/docs/meetings.html","text":"","title":"Meetings and Workshops"},{"location":"/docs/meetings.html#meetings-and-workshops","text":"","title":"Meetings and Workshops"},{"location":"/docs/meetings.html#up-coming-meetings","text":"TBD","title":"Up coming meetings"},{"location":"/docs/meetings.html#past-meetings","text":"","title":"Past meetings"},{"location":"/docs/meetings.html#incf-neuroinformatics-2018-montreal","text":"This meeting was organised 8th of August during the Brainhack hackathon organised the day before the INCF Neuroinformatics 2018 conference. It was the first one for the INCF Neuroshapes Special Interest Group. The goal was mainly to present Neuroshapes motivation to the Neuroscience community at INCF NI2018 but also to connect with other data sharing and open science initiatives like NIDM to see if they can adopt Neuroshapes’ approach in term of data modelling. Participants showed interest in using the W3C SHACL specification, as a way to complement existing data models with data validation capability. They showed interest in the ability to describe what are the expected properties of a dataset by mean of schemas using json-ld (semantic markups) and W3C SHACL.\nNote Read the full meeting report here.","title":"INCF Neuroinformatics 2018, Montreal"},{"location":"/docs/license.html","text":"","title":"License"},{"location":"/docs/license.html#license","text":"Note All Neuroshapes data models and example data are licensed under CC-BY-4.0.","title":"License"},{"location":"/docs/contact.html","text":"","title":"Contact"},{"location":"/docs/contact.html#contact","text":"Note Contact the INCF Special Interest Group on Neuroshapes.","title":"Contact"},{"location":"/docs/releases.html","text":"","title":"Release Notes"},{"location":"/docs/releases.html#release-notes","text":"","title":"Release Notes"},{"location":"/docs/releases.html#neuroshapes-1-0-x","text":"The main goal of Neuroshapes is to provide design patterns, best practices as well as tools to promote:\nThe use of standard semantic markups and linked data principles as ways to structure metadata and related data. The use of the W3C SHACL (Shapes Constraint Language) recommendation as a rich metadata schema language which is formal and expressive; interoperable; machine-readable; and domain-agnostic. The reuse of existing schemas and semantic markups ( schema.org , W3C PROV-O ) and existing ontologies and controlled vocabularies (including NIFSTD - Neuroscience Information Framework Standard Ontologies). The use of the W3C PROV-O recommendation as a format to record (meta)data provenance.\nIn Neuroshapes, many neuroscience data types are specified based on the key scientific and technical activities and agents that lead to their generation. The specifications are defined in validatable provenance-based data models and implemented using open and interoperable semantic web technologies.\nNeuroshapes has been used in production within various organisations for more than a year.\nFind below the notable changes from the previous release.","title":"Neuroshapes 1.0.x"},{"location":"/docs/releases.html#vocabulary-taxonomy-and-ontology-changes","text":"Neuroshapes main approach has been to build on top of existing initiatives for common (http://schema.org) and provenance (https://www.w3.org/TR/prov-o/) vocabularies. The v1.0.x release includes major alignment in terms of vocabularies with a systematic map to schema.org and W3C PROV-O if relevant and available:\nnsg:datePublished => schema:datePublished dcterms:hasPart => schema:hasPart nsg:hasPart => schema:hasPart dcterms:isPartOf => schema:isPartOf dcat:Distribution => schema:DataDownload nsg:endedAtTime => prov:endedAtTime nsg:startedAtTime => prov:startedAtTime schema:mediaType => schema:encodingFormat dcat:downloadURL => schema:contentUrl dcat:accessURL => schema:url nxv:digest => nsg:digest nsg:Entity => prov:Entity nsg:Activity => prov:Activity nsg:SoftwareAgent => prov:SoftwareAgent nsg:Organization => schema:Organization nsg:Person => schema:Person nsg:Collection => prov:Collection nsg:Collection => nsg:SubjectCollection nsg:Collection => prov:Collection nsg:EmptyCollection => prov:EmptyCollection\nThe above mapping brings unicity in term of types (e.g. no more nsg:Activity and prov:Activity).\nTwo new namespaces are introduced:\nhttps://neuroshapes.org/ with nsg as prefix: for all neuroscience specific types, properties and shapes. https://provshapes.org/ with prov as prefix: for all W3C PROV-0 provenance related types, properties and shapes.\nA core ontology is now introduced. It contains a set of types along with their definitions. The neurosciencegraph core data and schema contexts are also removed to avoid having users to manage them with multiple versions. Instead, the two contexts will only be generated upon Neuroshapes release:\ndata context: this context is identified by and accessible at https://incf.github.io/neuroshapes/contexts/data.json schema context: this context is identified by and accessible at https://incf.github.io/neuroshapes/contexts/schema.json\nThis release represents a commitment to backwards compatibility for contexts, vocabulary and ontologies in all future releases.","title":"Vocabulary, taxonomy and ontology changes"},{"location":"/docs/releases.html#shapes-changes","text":"Added:\ncontribution, license and language shapes taxonomy and ontology shapes boundingbox shape distribution shape BrainLocation shape\nRemoved:\nmediatype schema https://neuroshapes.org/dash/agent schema https://provshapes.org/dash/activity schema https://provshapes.org/dash/person https://provshapes.org/dash/organization https://provshapes.org/dash/entity schema https://provshapes.org/dash/collection Reused usage shape in activity shape\nConstraints:\nWholeCellPatchClamp activity now used nsg:SliceCollection instead of nsg:Slice WholeCellPatchClamp activity now is not required to have one generated entity","title":"Shapes changes"},{"location":"/docs/releases.html#technical-and-repository-structure-changes","text":"Previously, Neuroshapes’ github repository was made of multiple scala modules with one module for each neuroscience domain: Neuron Morphology, Brain Atlas, Ephys recording,… A set of shapes representing neuroscience entities were defined in each module. The Neuroshapes scala modules themselves imported provenance shapes from BlueBrain/nexus-prov and some BlueBrain Nexus built-in shapes. This structure was complex and was not easy to understand and relate with the main goals of Neuroshapes.\nThe v1.0.x release comes with a single scala module and a new simplified Github structure clearly showing:\nthe recommended taxonomies: in taxonomies dir the recommended ontologies: in ontologies dir the defined shapes for provenance description and for neuroscience entities and data types: in shapes dir. The shapes dir contains two categories of shapes: ** the provenance ones in shapes/prov: which are now located in the Neuroshapes Github repository instead of being inherited from BlueBrain/nexus-prov. ** the neuroscience ones: in shapes/neurosciencegraph\nShapes are now grouped in two categories:\ncommon shapes: these are libraries of useful shapes built mainly for reuse (e.g. QuantitativeValue). They often don’t define a target thus preventing them from being used alone to validate data. The related namespaces are:\n** https://neuroshapes.org/commons/ ** https://provshapes.org/commons/\ndata shapes (https://neuroshapes.org/dash/): these shapes to be used to validate actual data. They often make use of common shapes and define a target. The related namespaces are:\n** https://neuroshapes.org/dash/ ** https://provshapes.org/dash/","title":"Technical and Repository structure changes"},{"location":"/docs/shacl-tutorial/overview/shape-target.html","text":"","title":"Target declaration"},{"location":"/docs/shacl-tutorial/overview/shape-target.html#target-declaration","text":"Because graph like RDF does not have root node.\nA shape can define the nodes it will select and validate in a given data graph. It does so by declaring a target. Four different target declarations exist in SHACL as described in the following sections:\nNode target using the key targetNode Class target using the key targetClass Property Subject target using the key targetSubjectsOf Property Object target using the key targetObjectsOf\nNote that selected nodes for every target below are identified by a green line color.","title":"Target declaration"},{"location":"/docs/shacl-tutorial/overview/shape-target.html#node-target","text":"A shape can target very specific instances (nodes) by specifying their URIs through a targetNode:\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/Circuit_1_2\",\n \"@type\" : \"sh:NodeShape\",\n \"targetNode\" : [\"bbp:Circuit_1\",\"bbp:Circuit_2\"]\n } ]\n}\nThe instances identified by bbp:Circuit_1 and bbp:Circuit_2 are targeted in the figure above.","title":"Node target"},{"location":"/docs/shacl-tutorial/overview/shape-target.html#class-target","text":"The following schema defines one node shape which targets all instances of the class bbp:Entity. So only nodes that has bbp:Entity as direct type (**bb:Entity_1**) or indirect type (**bbp:Circuit_1** and bbp:Circuit_2) will be validated while all the other nodes are ignored.\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/Entity\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Entity\"\n } ]\n}","title":"Class target"},{"location":"/docs/shacl-tutorial/overview/shape-target.html#property-object-target","text":"A shape can target nodes that are objects of a specific property through targetObjectsOf.\nThis target will select any node that participate to the following triple as object: (subject, property, SelectedNode). In the figure below, there are two selected nodes (**bbp:Morphology_1** and bbp:Morphology_2) which respectively participate to the following two triples:\n*(bbp:Circuit_1, bbp:morphology, bbp:Morphology_1) *(bbp:Circuit_2, bbp:morphology, bbp:Morphology_2)\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertyObject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetObjectsOf\" : \"bbp:morphology\"\n } ]\n}","title":"Property Object target"},{"location":"/docs/shacl-tutorial/overview/shape-target.html#property-subject-target","text":"This target is the subject counterpart of the previous one. A shape can target nodes that are subjects of a specific property through targetSubjectsOf. So any nodes that are subjects of a triple with the target property as predicate will be selected: (**SelectedNode**, property, object).\nIn the figure below, there are two selected nodes (**bbp:Circuit_1** and bbp:Circuit_2) which respectively participate to the following two triples:\n(**bbp:Circuit_1**, bbp:morphology, bbp:Morphology_1) (**bbp:Circuit_2**, bbp:morphology, bbp:Morphology_2)\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertySubject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetSubjectsOf\" : \"bbp:morphology\"\n } ]\n}","title":"Property Subject target"},{"location":"/docs/data-models/ngv/new.html","text":"","title":"title"},{"location":"/docs/data-models/ngv/new.html#title","text":"","title":"title"},{"location":"/docs/data-models/ngv/new.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/ngv/new.html#description","text":"This specification describes metadata","title":"Description"},{"location":"/docs/data-models/ngv/new.html#competency-questions-to-be-completed-","text":"The following points describe a subset of questions :\nGet the reactions in a given pathway","title":"Competency questions (to be completed)"},{"location":"/docs/data-models/ngv/new.html#entities","text":"The different entity types involved are described below.\nType Description Reaction description Pathway description","title":"Entities"},{"location":"/docs/data-models/ngv/new.html#activities","text":"The different activity types involved are described below.\nType Description Activity description","title":"Activities"},{"location":"/docs/data-models/ngv/new.html#agents","text":"The different agent types involved are described below.\nType Description Agent description","title":"Agents"},{"location":"/assets/contexts/nexus/core/shacl20170720/prefixmapings.html","text":"Prefix Name Namespace sh http://www.w3.org/ns/shacl# shsh http://www.w3.org/ns/shacl-shacl# rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs http://www.w3.org/2000/01/rdf-schema# owl http://www.w3.org/2002/07/owl# xsd http://www.w3.org/2001/XMLSchema# prov http://www.w3.org/ns/prov# skos http://www.w3.org/2004/02/skos/core# schema http://schema.org/ nxv https://bbp-nexus.epfl.ch/vocabs/nexus/core/terms/v0.1.0/ nsg https://bbp-nexus.epfl.ch/vocabs/bbp/neurosciencegraph/core/v0.1.0/ ex http://example.org/","title":""},{"location":"/docs/data-models/minds/minds.html","text":"","title":"MINDS"},{"location":"/docs/data-models/minds/minds.html#minds","text":"","title":"MINDS"},{"location":"/docs/data-models/minds/minds.html#overview","text":"Put the abstract model here","title":"Overview"},{"location":"/docs/data-models/minds/minds.html#competency-questions","text":"The questions this model address","title":"Competency questions"},{"location":"/docs/data-models/minds/minds.html#schemas","text":"Vocabulary and constraints. Give an overview here and link towards","title":"Schemas"},{"location":"/docs/data-models/minds/minds.html#ontologies","text":"Recommended ontologies to use","title":"Ontologies"},{"location":"/docs/data-models/minds/minds.html#taxonomies","text":"Recommended taxonomies to use","title":"Taxonomies"},{"location":"/docs/data-models/minds/taxonomy.html","text":"","title":"Taxonomy"},{"location":"/docs/data-models/minds/taxonomy.html#taxonomy","text":"List of use cases: TBD","title":"Taxonomy"},{"location":"/docs/shacl-tutorial/how-to/_write-shacl-schemas.html","text":"","title":"Write a good shacl schemas"},{"location":"/docs/shacl-tutorial/how-to/_write-shacl-schemas.html#write-a-good-shacl-schemas","text":"","title":"Write a good shacl schemas"},{"location":"/docs/datamodeling/why-validation.html","text":"","title":"Why Data Validation ?"},{"location":"/docs/datamodeling/why-validation.html#why-data-validation-","text":"","title":"Why Data Validation ?"},{"location":"/docs/datamodeling/why-validation.html#data-validation-as-separate-steps","text":"https://code.tutsplus.com/tutorials/validating-data-with-json-schema-part-1--cms-25343","title":"Data Validation as separate steps"},{"location":"/docs/datamodeling/why-validation.html#why-schemas-","text":"","title":"Why schemas ?"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_index.html","text":"","title":"Nexus Schema Best Practices"},{"location":"/docs/shacl-tutorial/shacl-schemas-best-practices/_index.html#nexus-schema-best-practices","text":"","title":"Nexus Schema Best Practices"},{"location":"/docs/publication/index.html","text":"","title":"Publications"},{"location":"/docs/publication/index.html#publications","text":"","title":"Publications"},{"location":"/docs/datamodeling/linkeddata/index.html","text":"","title":"Thinking in Linked Data"},{"location":"/docs/datamodeling/linkeddata/index.html#thinking-in-linked-data","text":"test test test test tst test est","title":"Thinking in Linked Data"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_shape-target.html","text":"","title":"Target declarations ?"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_shape-target.html#target-declarations-","text":"A shape can define the nodes it will selects in a given data graph and validate. It does so by declaring a target.\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Entity\",\n \"@type\" : \"sh:NodeShape\",\n \"description\" : \"A node shape.\",\n \"targetClass\" : \"prov:Entity\"\n } ]\n}","title":"Target declarations ?"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_shape-target.html#shape","text":"How a shape works? SHACL Validation flow\nGiven an input data graph (a json-ld document):\nNode to be focused on for validation are selected using targets: list the different targets Filters can be used to eliminate some focused nodes Validate focused nodes using constraints","title":"Shape"},{"location":"/docs/shacl-tutorial/tutorial-example/researcher.html","text":"","title":"A little Academic Publishing Domain"},{"location":"/docs/shacl-tutorial/tutorial-example/researcher.html#a-little-academic-publishing-domain","text":"The produced domain model should support the following queries: that is to say the competency questions.\nGet the researcher’s description Get the researcher’s area of studies Get the researcher’s affiliations Get the researcher’s publications Get the researcher’s current and past grants\nTo answer the above questions, the following entities need to be considered:\nResearcher Researchers’ affiliations which are organisations Research Grant Scientific Publication\nLet adopt a knowledge graph perspective to illustrate this domain:\nEach of the above entities needs to be described using a given set of properties.\nAll of the above entities can be described using metadata from schema.org. A Researcher can be described with the following set of metadata:\nProperty Description name The researcher name given name Brain slice obtained from the specimen affiliations Brain slice with patched cells PatchedCellCollection Collection of patched cells in a single slice PatchedCell Cell that was patched in the slice Trace Individual recording trace of the patched cell (StimulationTrace and ResponseTrace) Protocol Document that describes the method used in the design and implementation of an experiment\nHopefully To help answer the above questions, the following datasets will be used:\nSource:\norcid springer nature","title":"A little Academic Publishing Domain"},{"location":"/docs/data-models/minds/vocabulary.html","text":"","title":"Vocabulary"},{"location":"/docs/data-models/minds/vocabulary.html#vocabulary","text":"","title":"Vocabulary"},{"location":"/docs/data-models/minds/vocabulary.html#namespaces","text":"List of use cases: TBD","title":"Namespaces"},{"location":"/docs/shacl-tutorial/how-to/_index.html","text":"","title":"How to"},{"location":"/docs/shacl-tutorial/how-to/_index.html#how-to","text":"","title":"How to"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html","text":"","title":"Brain Atlas Derivation"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html#brain-atlas-derivation","text":"","title":"Brain Atlas Derivation"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html#description","text":"TBD","title":"Description"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html#competency-questions","text":"TBD","title":"Competency questions"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html#provenance-pattern","text":"Link towards the provenance pattern: TBD","title":"Provenance pattern"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html#entities","text":"The different entity types involved are described below.\nType Description An Entity type A description","title":"Entities"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html#activities","text":"Type Description An activity Type A description","title":"Activities"},{"location":"/docs/data-models/brainatlas/brain-atlas-derivation.html#agents","text":"Type Description An Agent Types A description","title":"Agents"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_index.html","text":"","title":"Shacl overview"},{"location":"/docs/shacl-tutorial/shacl-shapes-definition/_index.html#shacl-overview","text":"","title":"Shacl overview"},{"location":"/docs/data-models/neuronclassification/neuronclassification.html","text":"","title":"Literature Annotation"},{"location":"/docs/data-models/neuronclassification/neuronclassification.html#literature-annotation","text":"","title":"Literature Annotation"},{"location":"/docs/data-models/neuronclassification/neuronclassification.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/neuronclassification/neuronclassification.html#description","text":"Axon projection M-type\nSteps: - Get all cell types","title":"Description"},{"location":"/docs/data-models/neuronclassification/neuronclassification.html#competency-questions","text":"","title":"Competency questions"},{"location":"/docs/data-models/neuronclassification/neuronclassification.html#abstract-data-model","text":"","title":"Abstract Data model"},{"location":"/docs/shacl-tutorial/overview/validation-flow-old.html","text":"","title":"Validation flow"},{"location":"/docs/shacl-tutorial/overview/validation-flow-old.html#validation-flow","text":"Data validation using a SHACL processor involves two type of resources:\na shape defining the constraints the data should conform to: the shape is called shapes graph in the W3C SHACL recommendation. the data to be validated against the shape: called data graph in the W3C SHACL recommendation\nGiven a shape and a data as inputs, a SHACL processor starts by selecting what part of the data to focus on and then validate whether that part conforms to the shape graph or not.","title":"Validation flow"},{"location":"/docs/shacl-tutorial/overview/validation-flow-old.html#data-selection","text":"A shape can specify the nodes it will validate within a data graph by using one or many target declarations. A shape can target:\na specific node What to validate What to validate What to validate\nThe target declarations section provides in depth explanation about the different ways for a shape to select a node to validate.\nBut why does a target selection mechanism needed ? Why isn’t all the data graph validated against a shape? The answer lies in the graph nature of json-ld data structure in which there is no root node. Which node is the root or the ‘main’ one in the following example showing a description of the professor Jane Doe ? Is it the node Jane Doe or EPFL ?\nis a graph data model and as such does not have SHACL starts by selecting nodes in the data graph targeted by each shape in the shapes graph. The selected nodes are called focused nodes.\nShapes need to declare the node target the nodes they should validate because of the graph nature of JSON-LD: there is no root in a graph data model. 2 s A target","title":"Data selection"},{"location":"/docs/shacl-tutorial/overview/validation-flow-old.html#data-filtering","text":"Filters can be used to eliminate some focused nodes","title":"Data filtering"},{"location":"/docs/shacl-tutorial/overview/validation-flow-old.html#data-validation","text":"","title":"Data validation"},{"location":"/docs/shacl-tutorial/overview/_why-shacl.html","text":"","title":"Why SHACL ?"},{"location":"/docs/shacl-tutorial/overview/_why-shacl.html#why-shacl-","text":"","title":"Why SHACL ?"},{"location":"/docs/shacl-tutorial/overview/overview.html","text":"","title":"SHACL Overview"},{"location":"/docs/shacl-tutorial/overview/overview.html#shacl-overview","text":"","title":"SHACL Overview"},{"location":"/docs/shacl-tutorial/overview/overview.html#shacl-core-components","text":"","title":"SHACL Core Components"},{"location":"/docs/shacl-tutorial/overview/overview.html#a-validation-language-for-a-graph-data-model","text":"","title":"A validation language for a graph data model"},{"location":"/docs/shacl-tutorial/overview/overview.html#basic-definitions","text":"","title":"Basic definitions"},{"location":"/docs/shacl-tutorial/namespaces.html","text":"","title":"Namespaces declaration"},{"location":"/docs/shacl-tutorial/namespaces.html#namespaces-declaration","text":"This document explains web user interfaces and application programming interfaces that were developed by Neuroinformatics Platform (NIP) during the Ramp-Up phase of the Human Brain Project (HBP) that took place between October 2013 and March 2016. The applications are directly available for users and their first versions were launched at the end of the Ramp-Up phase.","title":"Namespaces declaration"},{"location":"/assets/provtemplates/README.html","text":"","title":"Provenance Templates"},{"location":"/assets/provtemplates/README.html#provenance-templates","text":"","title":"Provenance Templates"},{"location":"/docs/tools/index.html","text":"","title":"Software and Tools"},{"location":"/docs/tools/index.html#software-and-tools","text":"","title":"Software and Tools"},{"location":"/docs/shacl-tutorial/further-readings/_index.html","text":"","title":"Overview"},{"location":"/docs/shacl-tutorial/further-readings/_index.html#overview","text":"much to learn you still have","title":"Overview"},{"location":"/docs/data-models/ngv/molecule.html","text":"","title":"title"},{"location":"/docs/data-models/ngv/molecule.html#title","text":"","title":"title"},{"location":"/docs/data-models/ngv/molecule.html#use-case","text":"","title":"Use case"},{"location":"/docs/data-models/ngv/molecule.html#description","text":"Description of type of molecules like protein refereing external databases.","title":"Description"},{"location":"/docs/data-models/ngv/molecule.html#competency-questions-to-be-completed-","text":"The following points describe a subset of questions :\nGet the reactions in a given pathway","title":"Competency questions (to be completed)"},{"location":"/docs/data-models/ngv/molecule.html#entities","text":"The different entity types involved are described below.\nType Description Reaction description Pathway description","title":"Entities"},{"location":"/docs/data-models/ngv/molecule.html#activities","text":"The different activity types involved are described below.\nType Description Activity description","title":"Activities"},{"location":"/docs/data-models/ngv/molecule.html#agents","text":"The different agent types involved are described below.\nType Description Agent description","title":"Agents"},{"location":"/docs/shacl-tutorial/further-readings/_what-is-shacl.html","text":"","title":"What is SHACL ?"},{"location":"/docs/shacl-tutorial/further-readings/_what-is-shacl.html#what-is-shacl-","text":"shapes RDF","title":"What is SHACL ?"},{"location":"/docs/shacl-tutorial/index-old.html","text":"","title":"SHACL vs OWL ?"},{"location":"/docs/shacl-tutorial/index-old.html#shacl-vs-owl-","text":"To understand the difference between SHACL and OWL inference for example let consider the following example:\nowl: for an instanve to be a person, it has to have a name => necessary and/or sufficient defining conditions useful for classification SHACL: if you are a person then you should have a name => mandatory or optional conditions to meet expectations","title":"SHACL vs OWL ?"},{"location":"/docs/shacl-tutorial/index-old.html#introduction-to-shacl","text":"This document presents an example-driven tutorial on how to build a linked data model for a given domain of application using:\nW3C SHACL recommendation as a data modeling language Blue Brain Nexus as a data management and publishing platform.\nThroughout this document, a simple example of a domain of interest is developed. The example, illustrate different linked data modeling challenges and requirements and demonstrate how they can be met by leveraginb Knowledge about linked data and the Nexus platform REST API is recommended even though not mandatory. You can view the following excellent video on Linked data on youtube.\nNote This tutorial makes use of a SHACL Playground to tests that data conform to schemas. The Nexus explorer will be used to view and navigate the built linked data models.\nThe tutorial is organised as follows:\nA presentation of the data examples that will be used throughout this tutorial","title":"Introduction to SHACL"},{"location":"/docs/shacl-tutorial/getting-started.html","text":"","title":"Getting Started in 5 mn"},{"location":"/docs/shacl-tutorial/getting-started.html#getting-started-in-5-mn","text":"","title":"Getting Started in 5 mn"},{"location":"/docs/shacl-tutorial/getting-started.html#install-the-nexus-cli","text":"pip install nexus-cli","title":"Install the Nexus CLI"},{"location":"/docs/shacl-tutorial/getting-started.html#create-a-new-working-space-in-nexus-sandbox","text":"nexus init","title":"Create a new working space in Nexus sandbox"},{"location":"/docs/shacl-tutorial/getting-started.html#set-acls","text":"nexus init","title":"Set acls"},{"location":"/docs/shacl-tutorial/getting-started.html#define-a-data-model","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/Circuit_1_2\",\n \"@type\" : \"sh:NodeShape\",\n \"targetNode\" : [\"bbp:Circuit_1\",\"bbp:Circuit_2\"]\n } ]\n}","title":"Define a data model"},{"location":"/docs/shacl-tutorial/getting-started.html#push-data","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/Circuit_1_2\",\n \"@type\" : \"sh:NodeShape\",\n \"targetNode\" : [\"bbp:Circuit_1\",\"bbp:Circuit_2\"]\n } ]\n}","title":"Push data"},{"location":"/docs/shacl-tutorial/getting-started.html#query-your-data","text":"
    \n \t\t\t
    typed.js — bash — 80x10
    \n \t\t\t
    \n \t\t\t\t$ Try it out!|\n \t\t\t
    \n \t\t
    ","title":"Query your data"},{"location":"/docs/shacl-tutorial/getting-started.html#data-examples","text":"","title":"Data examples"},{"location":"/docs/shacl-tutorial/tutorial-example/index.html","text":"","title":"A little Academic Publishing Domain"},{"location":"/docs/shacl-tutorial/tutorial-example/index.html#a-little-academic-publishing-domain","text":"For the purpose of this tutorial let consider a scientific publisher that wants to build an application to manage publication data. Let call this application domain an academic publishing domain within which there is a researcher named Anna whom activities need to be modeled and queried. Anna works at the NEXT-AI laboratory of the NEXT-School, a world renowned research institution. She is specialized in Artificial intelligence, a research area for which she is one of the top contributors as she published many scientific articles in top AI journals as well as many AI related books. She is recipiendaire of many international grants from public research funding agencies like EU ERC grant that she won in collaboration with other researchers.","title":"A little Academic Publishing Domain"},{"location":"/docs/shacl-tutorial/tutorial-example/index.html#knowledge-graph-perspective","text":"Let adopt a knowledge graph perspective to illustrate this domain entities and relations:","title":"knowledge graph perspective"},{"location":"/docs/shacl-tutorial/tutorial-example/index.html#the-domain-competency-questions","text":"The produced data model should support the following queries: that is to say the model competency questions:\nGet the researcher’s metadata (e.g. famillyName, givenName, email) Get the researcher’s area of studies (e.g. famillyName, givenName, email) Get the researcher’s affiliations Get the researcher’s publications Get the researcher’s current and past grants What are the researchers that co-author a scientific article with Anna ?","title":"The domain competency questions"},{"location":"/docs/shacl-tutorial/tutorial-example/index.html#the-domain-entities","text":"To answer the above questions, the following entities need to be considered:\nResearcher Researchers’ affiliations which are organisations Research Grant Scientific Publication\nEach of the above entities needs to be described using a given set of properties.\nAll of the above entities can be described using metadata from schema.org. A Researcher can be described with the following set of metadata:\nProperty Description name The researcher name given name Brain slice obtained from the specimen affiliations Brain slice with patched cells PatchedCellCollection Collection of patched cells in a single slice PatchedCell Cell that was patched in the slice Trace Individual recording trace of the patched cell (StimulationTrace and ResponseTrace) Protocol Document that describes the method used in the design and implementation of an experiment\nHopefully To help answer the above questions, the following datasets will be used:\nSource:\norcid springer nature","title":"The domain entities"},{"location":"/docs/shacl-tutorial/tutorial-example/start-simple.html","text":"","title":"Start simple"},{"location":"/docs/shacl-tutorial/tutorial-example/start-simple.html#start-simple","text":"Let start out with very simple descriptions of the entities in the little publishing domain.","title":"Start simple"},{"location":"/docs/shacl-tutorial/tutorial-example/start-simple.html#researcher-description","text":"A Researcher can be described by a givenName, a familyName as well as its affiliations.\n{\n \"@context\":\"http://schema.org\",\n \"@type\" : \"Person\",\n \"giveName\" : \"Alice\",\n \"familyName\" : \"Alice\",\n \"affiliations\":[]\n}\nProperty Description familyName The researcher family name givenName The researcher given name affiliations The institutions (labs, universities,…) the researcher is affiliated to identifier The researcher persistent digital identifier orcid identifiers","title":"Researcher description"},{"location":"/docs/shacl-tutorial/tutorial-example/start-simple.html#organization-description","text":"Hopefully To help answer the above questions, the following datasets will be used:","title":"Organization description"},{"location":"/docs/shacl-tutorial/tutorial-example/start-simple.html#grant-description","text":"","title":"Grant description"},{"location":"/docs/shacl-tutorial/tutorial-example/start-simple.html#scientific-publication-description","text":"","title":"Scientific Publication description"},{"location":"/docs/shacl-tutorial/overview/data-modeling-approach.html","text":"","title":"Data modeling approach"},{"location":"/docs/shacl-tutorial/overview/data-modeling-approach.html#data-modeling-approach","text":"Shapes are different from types closed shapes: anyone can say anything about anything least power","title":"Data modeling approach"},{"location":"/docs/datamodeling/linkeddata/rdf/index.html","text":"","title":"JSON for Linking Data"},{"location":"/docs/datamodeling/linkeddata/rdf/index.html#json-for-linking-data","text":"Note This section introduces basic concepts of JSON for Linked Data (JSON-LD). The reader should look at the JSON-LD specification for in-depth documentation.\nJSON-LD is a very flexible format allowing multiple json representation for the same content as shown in the following example:","title":"JSON for Linking Data"},{"location":"/docs/datamodeling/linkeddata/rdf/index.html#why-json-ld-","text":"First of all a json-ld document is a json document. So what is the difference ? To help answer the question, let consider the following json document:\n{\n \"identifier\" : \"0e3b328c-c18f-4e64-9a0e-f6e4f32b36da\",\n \"python\":\"fast\",\n \"java\" : \"\"\n}\nWhat this document is about ? Python and Java as programming languages or as snake and the indonesia island respectively ? The json document is ambiguous. With just the payload, human and software agents can’t confidently infer the document topic without knowing from which endpoint it was obtained.\nsemantic preserving data exchange\nJson-ld specification was created to solve the above ambiguity issue among other features it brings to the way web resources are exchanged through API. To enable semantic preserving data exchange, it adds a context object to the json document within which each json keys and/or values can be mapped to a unique identifier as shown in the following document:\n{\n \"@context\":{\n \"python\":\"http://programminglanguages.org/python\",\n \"java\":\"http://programminglanguages.org/java\",\n \"identifier\":\"@id\"\n },\n \"identifier\" : \"0e3b328c-c18f-4e64-9a0e-f6e4f32b36da\",\n \"python\":\"fast\",\n \"java\" : \"\"\n}\nA JSON-LD context is simply a mapping:\nfrom a key often called prefix and sometimes aliases: python, java as well as identifier are prefixes to a value often called namespace: *http://programminglanguages.org/python* is a namespace\nNote The JSON-LD document can be seen within the json-ld playground.\nWhen written with a context object, a JSON-LD document is said to be compacted. On the opposite, the json-ld context is said expanded when its context is applied, i.e all prefixes as well as aliases are replaced by their corresponding namespaces. Find below the expanded form of the json-ld document example above:\n{\n \"@id\" : \"0e3b328c-c18f-4e64-9a0e-f6e4f32b36da\",\n \"http://programminglanguages.org/python\":\"fast\",\n \"http://programminglanguages.org/java\" : \"\"\n}","title":"Why JSON-LD ?"},{"location":"/docs/datamodeling/linkeddata/rdf/index.html#json-ld-data-model","text":"A JSON-LD document can be seen a json tree or as a RDF document (Resource description Framework).\nNote The reader can checkout the full RDF recommendation here.\nAs one of the multiple RDF document serialization format, a JSON-LD document can be seen as a directed graph where every of piece of knowledge about a thing always comes in three and is broken down in (**subject, predicate, object**):\n(subject, predicate, object) is often called a statement, an assertion, a fact or more technically a triple just like in most programming languages (python, java,…). So a JSON-LD document can be seen as a collection of triples.\nThe graph vocabulary is often used when naming elements of a triple:\nthe subject and the object are called nodes while the predicate is called property or arc\nHere is the set of triples corresponding to the json-ld document above:\n…","title":"JSON-LD data model"},{"location":"/docs/datamodeling/linkeddata/rdf/index.html#cool-uris-dont-change","text":"Elements of a JSON-LD document have URIs as identifiers. For example, the URI of the Allen human brain atlas ontology (as integrated in NIP) is http://api.brainmap.org/api/v2/data/Structure, while the URI of the specific term “gray matter” is http://api.brainmap. org/api/v2/data/Structure/4006 . The previous two URIs can have a short form which is called prefix (a stable string) for the ontology and CURIE for the ontology entities. Let take again the previous example. The prefix name of (the short form of) “ http://api.brainmap. org/api/v2/data/Structure ” can be ‘HBA’ while the curie of the term ’’grey matter\" is ‘HBA:4006’. Given the curie ‘HBA:4006’, ‘HBA’ is the prefix name and ‘4006’ is the fragment.","title":"Cool URIs don’t change"},{"location":"/docs/datamodeling/linkeddata/rdf/index.html#further-reading","text":"JSON-LD Best Practices\nJSON-LD","title":"Further reading"},{"location":"/docs/datamodeling/linkeddata/rdf/uris.html","text":"","title":"Cool URIs dont change"},{"location":"/docs/datamodeling/linkeddata/rdf/uris.html#cool-uris-dont-change","text":"","title":"Cool URIs don’t change"},{"location":"/docs/datamodeling/linkeddata/rdf/json-ld.html","text":"","title":"JSON-LD"},{"location":"/docs/datamodeling/linkeddata/rdf/json-ld.html#json-ld","text":"SHACL is for validating data represented using the Resource Description Framework (RDF). So, before starting to describe SHACL in details, it is important to introduce some concepts of RDF. The goal of this section is not to fully describe RDF data model but rather introduce some of its core concepts that are necessary to understand SHACL.","title":"JSON-LD"},{"location":"/docs/datamodeling/linkeddata/rdf/readings.html","text":"","title":"Further Reading"},{"location":"/docs/datamodeling/linkeddata/rdf/readings.html#further-reading","text":"","title":"Further Reading"},{"location":"/docs/data-models/minds/namespace.html","text":"","title":"Namespace"},{"location":"/docs/data-models/minds/namespace.html#namespace","text":"List of use cases: TBD","title":"Namespace"},{"location":"/docs/data-models/minds/schemas.html","text":"","title":"Schemas"},{"location":"/docs/data-models/minds/schemas.html#schemas","text":"List of use cases: TBD","title":"Schemas"},{"location":"/docs/shacl-tutorial/nexus-kg-schemas/_index.html","text":"","title":"Nexus KG schemas"},{"location":"/docs/shacl-tutorial/nexus-kg-schemas/_index.html#nexus-kg-schemas","text":"","title":"Nexus KG schemas"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html","text":"","title":"What is SHACL ?"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#what-is-shacl-","text":"","title":"What is SHACL ?"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#reference-documentation","text":"","title":"Reference documentation"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#context-and-namespaces","text":"","title":"Context and Namespaces"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#validation-flow","text":"How a shape works?\nGiven an input RDF data graph (a json-ld document):\nNode to be focused on for validation are selected using targets Filters can be used to eliminate some focused nodes Validate focused using constraints","title":"Validation flow"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#target-declaration","text":"A shape can define the nodes it will select and validate in a given data graph. It does so by declaring a target. Four different target declarations exist in SHACL as described in the following sections:\nNode target using the key targetNode Class target using the key targetClass Property Subject target using the key targetSubjectsOf Property Object target using the key targetObjectsOf\nNote that selected nodes for every target below are identified by a green line color.","title":"Target declaration"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#node-target","text":"A shape can target very specific instances (nodes) by specifying their URIs through a targetNode:\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/Circuit_1_2\",\n \"@type\" : \"sh:NodeShape\",\n \"targetNode\" : [\"bbp:Circuit_1\",\"bbp:Circuit_2\"]\n } ]\n}\nThe instances identified by bbp:Circuit_1 and bbp:Circuit_2 are targeted in the figure above.","title":"Node target"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#class-target","text":"The following schema defines one node shape which targets all instances of the class bbp:Entity. So only nodes that has bbp:Entity as direct type (**bb:Entity_1**) or indirect type (**bbp:Circuit_1** and bbp:Circuit_2) will be validated while all the other nodes are ignored.\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/Entity\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Entity\"\n } ]\n}","title":"Class target"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#property-object-target","text":"A shape can target nodes that are objects of a specific property through targetObjectsOf.\nThis target will select any node that participate to the following triple as object: (subject, property, SelectedNode). In the figure below, there are two selected nodes (**bbp:Morphology_1** and bbp:Morphology_2) which respectively participate to the following two triples:\n*(bbp:Circuit_1, bbp:morphology, bbp:Morphology_1) *(bbp:Circuit_2, bbp:morphology, bbp:Morphology_2)\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertyObject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetObjectsOf\" : \"bbp:morphology\"\n } ]\n}","title":"Property Object target"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#property-subject-target","text":"This target is the subject counterpart of the previous one. A shape can target nodes that are subjects of a specific property through targetSubjectsOf. So any nodes that are subjects of a triple with the target property as predicate will be selected: (**SelectedNode**, property, object).\nIn the figure below, there are two selected nodes (**bbp:Circuit_1** and bbp:Circuit_2) which respectively participate to the following two triples:\n(**bbp:Circuit_1**, bbp:morphology, bbp:Morphology_1) (**bbp:Circuit_2**, bbp:morphology, bbp:Morphology_2)\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertySubject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetSubjectsOf\" : \"bbp:morphology\"\n } ]\n}","title":"Property Subject target"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#constraints","text":"A shape can defined a set of constraints to be checked against selected nodes. The set of possible constraints can be divided into two categories:\nNodeKind constraint: about selected nodes themselves Property constraints: about outgoing or incoming properties of each selected node","title":"Constraints"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#nodekind-constraint","text":"The nodeKind constraint allows to choose if a selected need to be identified by an IRI eventually consistent with a specific pattern or if it can unidentified. At most one nodeKind constraint can be defined for a given NodeShape.\nThe following schema states that all values of the property bbp:morphology have to be nodes identified by IRIs.\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/MorphologyPropertyObject\",\n \"@type\" : \"sh:NodeShape\",\n \"targetObjectsOf\" : \"bbp:morphology\",\n \"nodeKind\": \"sh:IRI\"\n } ]\n}\nIn the previous example, the node “Morphology_1” (red border) is an object of the property bbp:morphology which is a Literal (precisely a string literal). So it’s not identifier by an IRI which makes it invalid. The node bbp:Morphology_2 (green border) on the other hand is valid because it is an object property of the property bbp:morphology and is identified by an IRI. All values of the nodeKind constraint are listed in the table below:\nValue Description sh:IRI The selected nodes have to be identified by a valid IRI. sh:BlankNode The selected nodes should not be identified by an IRI nor be a Literal. sh:Literal The selected nodes should be a Literal. sh:BlankNodeOrIRI Disjunctive combination of sh:BlankNode and sh:IRI. sh:BlankNodeOrLiteral Disjunctive combination of sh:BlankNode and sh:Literal. sh:IRIOrLiteral Disjunctive combination of sh:IRI and sh:Literal.","title":"NodeKind Constraint"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#property-constraints","text":"Definition of bbp:morphology as an outgoing property of any instance of bbp:Circuit:\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\"\n }\n } ]\n ]\n}\nGiven a selected node, a shape defines a set of outgoing and/or incoming properties as well as a set of constraints for each of them. By doing so, a shape enforce a vocabulary (a set of properties) to be used for describing the selected nodes (instances of bbp:Circuit in the schema for example) and how that vocabulary should be used (constraints).\nTo define a set of incoming and/or outgoing properties, the property key is used. It is an array and each of its item is an instance of a PropertyShape. The following tables describe the minimal keys to use in order to define a property:\nkey Description path MAandatory. Refers to the property IRI (“bbp:morphology” in the schema example) in case of outgoing property. For an incoming one, the following syntax is used: “path” : [ “sh:inversePath prov:generated” ]. name Optional. A human readable name of the property. The name can be used in generated forms for example. description Optional. Description of the property.\nOnce the property shape is defined, a set of constraints can be attached to it.\nCardinality Constraints\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:dataSpace\",\n \"name\" : \"Data Space\",\n \"description\" : \"Data Space.\",\n \"minCount\":\"1\"\n }\n ]\n }\n ]\n}\nHow many outgoing “bbp:morphology” properties a specific bbp:Circuit instance can have ? A question that can be reformulated as: how many triples following the pattern (bbp:Circuit_*, bbp:morphology, object) can exist in the data graph ? The answers can be: zero or more, exactly one, at most one. To enforce one of these answers a cardinality constraint can be defined and attached to a property shape as shown in the schema example. The default value for minCount and maxCount is 0.\nThe example schema states that all instances of bbp:Circuit should have at least one value for bbp:morphology property and at most 3 values. They should have at least one value for bbp:dataSpace property as well. In the example data graph below, bbp:Circuit_1 is valid because it has one value for bbp:morphology property and one value for bbp:dataSpace. On the other hand, bbp:Circuit_2 is not valid because it has not a value for bbp:dataSpace property.\nProperty Value Type Constraints\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:dataSpace\",\n \"name\" : \"Data Space\",\n \"description\" : \"Data Space.\",\n \"minCount\":\"1\"\n },\n {\n \"path\" : \"bbp:brainRegion\",\n \"name\" : \"Brain region\",\n \"description\" : \"Brain region.\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\",\n \"node\": \"circuitshape:LabeledOntologyTermShape\"\n },\n {\n \"path\" : \"schema:name\",\n \"name\" : \"Name\",\n \"description\" : \"Circuit name\",\n \"datatype\": \"xsd:string\",\n \"minCount\":\"1\",\n \"maxCount\":\"1\"\n }\n ]\n },\n {\n \"@id\" : \"circuitshape:LabeledOntologyTermShape\",\n \"@type\" : \"sh:NodeShape\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"rdfs:label\",\n \"name\" : \"label\",\n \"description\" : \"Human readable label\",\n \"datatype\": \"xsd:string\",\n \"maxCount\" : 1,\n \"minCount\" : 1\n\n }\n }\n ]\n}\nThe type of a property value can be restricted. In the schema example, all instances of bbp:circuit should have exactly one name which should be of type string. How to express such type restriction in a shacl schema ?\nPrimitive type as property value\nA property value can be of a primitive type: string, integer, double, anyURI, … and datatype key is used to define such primitive expected types as shown in the shacl schema example. The namespace of all primitive types is xsd and for a complete list of those types please check here.\nProperty values are not always primitive and two other typical situations may occurs.\nReference as property value\nThe type of a property value can be restricted to be an instance of a specific class. For example, it may be useful to enforce all values of the bbp:morphology property of a given circuit to be of type bbp:Morphology. To express this type of constraint the key class is used as shown in the schema example. The ability to constraint types is important to ensure the quality and reliability of the data being submitted into the Nexus platform and SHACL allows to do that without writing a single line of validation code.\nNode as property value\nSometimes it may be useful to enforce that a property value has a particular shape instead of being of a specific type. For example, we may want to enforce all brain region values of a all circuits (instances of bbp:Circuit) to have at least an IRI as identifier (“nodeKind”: “sh:IRI”) and a label as human readable description. The key node is used to express a shape constraint.","title":"Property Constraints"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#qualified-cardinality","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/shapes/Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"3\",\n \"maxCount\":\"3\"\n },\n {\n \"path\" : \"bbp:morphology\",\n \"qualifiedValueShape\": {\n \"class\" : \"bbp:RawMorphology\"\n },\n \"qualifiedValueShapesDisjoint\": true,\n \"qualifiedMinCount\":1,\n \"qualifiedMaxCount\":1\n },\n {\n \"path\" : \"bbp:morphology\",\n \"qualifiedValueShape\": {\n \"class\" : \"bbp:SynthesizedMorphology\"\n },\n \"qualifiedValueShapesDisjoint\": true,\n \"qualifiedMinCount\":1\n }\n ]\n }\n ]\n}\nCardinality constraints can be more complex than what is presented in the constraints section above. A complex cardinality use case can be expressed in the following way : *a bbp:Circuit instance should be linked with exactly 3 Morphologies (instances of bbp:Morphology) *exactly one of them should be a raw morphology (an instance of bbp:RawMorphology) *at least one of them should be synthesized morphology (an instance of bbp:SynthesizedMorphology) *and a bbp:Circuit instance can’t be at the same time of type bbp:RawMorphology and bbp:SynthesizedMorphology\nThe schema example shows how to implement the above constraints using the following keys:\nkey Description qualifiedValueShape Mandatory. The shape that the specified (through qualifiedMinCount and qualifiedMaxCount) number of nodes should be consistent with. qualifiedMinCount Mandatory. The minimum number of nodes that should be consistent with the shape in qualifiedValueShape qualifiedMaxCount Mandatory. The maximum number of nodes that should be consistent with the shape in qualifiedValueShape qualifiedValueShapesDisjoint Optional. If true then the values conform to the current property shape must not conform to the siblings property shapes","title":"Qualified Cardinality"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#combining-shapes","text":"Until now we’ve described how to define a shape that targets different nodes using different selectors and enforcing different type of constraints. But designing real life schemas is complex and often required reuse of already defined ones. Two use cases can occur when it comes to reuse SHACL schemas:\nreuse a shape by combining it with other shapes using boolean operators specialization mechanism between shapes","title":"Combining shapes"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#logical-combination-of-shapes","text":"A node shape definition for all instances of bbp:Entity\n{\n \"@id\" : \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\",\n \"shapes\" : [ {\n \"@id\" : \"this:EntityShape\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Entity\",\n \"nodeKind\": \"sh:IRI\",\n \"property\" : [{\n \"path\" : \"schema:name\",\n \"name\" : \"Name\",\n \"description\" : \"Entity name\",\n \"or\":[\n {\n \"datatype\": \"xsd:string\"\n },\n {\n \"datatype\": \"xsd:integer\"\n }\n ]\n },{\n \"path\" : \"schema:description\",\n \"name\" : \"Description\",\n \"description\" : \"The entity description\",\n \"datatype\" : \"xsd:string\"\n }\n ]\n }\n ]\n}\n{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"@type\": \"owl:Ontology\",\n \"imports\" : [ \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\"],\n \"shapes\" : [ {\n \"@id\" : \"this:Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"and\":[{\n \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\"\n },\n {\n \"property\" : [ {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n }\n ]\n }\n ]\n }\n ]\n}\nShapes can be combined using the following boolean operators:\nkey Description and The data has to be valid with respect to all combined shapes or The data has to be valid with respect to at least one shape xone The data has to be valid with respect to only one shape not The data should not be valid with respect to the given shape(s)\nIn the previous schema (identified by {endpoint}/schemas/bbp/simulation/circuit/v1.0.0/), the property shape related to schema:name property can be externalized in a schema ({endpoint}/schemas/bbp/core/entity/v1.0.0/) belonging to the “bbp” organization, “core” domain and named “entity” as shown in the right tab. Now let reuse (see in the right) the entity schema since a bbp:Circuit is a bbp:Entity as well. Basically, the schema is expressing that a bbp:Circuit instance should be consistent with respect to the schema for bbp:Entity (external one) and the one for bbp:Circuit (local one).\nNote the use of the **imports** key. It tells the shacl validator where to find the shapes that are referenced in the local schema: \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\" for example. Only published schemas can be imported.\nThe or, xone and not operators can be used in the same way as the and one. The example shows how to logically combined two node shapes. Property shapes can be combined as well as shown in the shape this:EntityShape where the property schema:name van be of type string of integer.\nAll shapes that are listed in the shapes array are by default considered combined in conjunctive way (and operator).","title":"Logical combination of shapes"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#shape-specialization","text":"{\n \"@id\" : \"{endpoint}/schemas/bbp/simulation/circuit/v1.0.0/\",\n \"@type\": \"owl:Ontology\",\n \"imports\" : [ \"{endpoint}/schemas/bbp/core/entity/v1.0.0/\"],\n \"shapes\" : [ {\n \"@id\" : \"this:Circuit\",\n \"@type\" : \"sh:NodeShape\",\n \"targetClass\" : \"bbp:Circuit\",\n \"nodeKind\": \"sh:IRI\",\n \"and\":[{\n \"node\":\"{endpoint}/schemas/bbp/core/entity/v1.0.0/shapes/EntityShape\"\n },\n {\n \"property\" : [\n {\n \"path\" : \"schema:description\",\n \"minCount\" : 1\n \"maxCount\" : 1\n },\n {\n \"path\" : \"bbp:morphology\",\n \"name\" : \"morphologies\",\n \"description\" : \"Collection of morphologies used in the circuit building.\",\n \"class\": \"bbp:Morphology\",\n \"minCount\":\"1\",\n \"maxCount\":\"3\"\n }\n ]\n }\n ]\n }\n ]\n}\nIn the previous section, the circuit schema example already introduces a bit the way a shape can be specialized. Indeed combining shapes using the and boolean operator conveys a sense of extension. But the specialization can go further than just adding more constraints on top of a reused schema. The this:Circuit can further constraint the use of the schema:description property in all bbp:Circuit instances by setting a minimal and a mawimal cardinality. All bbp:Circuit instances must have exactly one value for the property schema:description whereas it’s not mandatory for other bbp:Entity instances.\nNote that only the and boolean operator can be used for shape specialization.","title":"Shape specialization"},{"location":"/docs/shacl-tutorial/overview/what-is-shacl.html#frequent-shacl-validation-errors","text":"WIP","title":"Frequent SHACL validation errors"},{"location":"/docs/shacl-tutorial/nexus-kg-schemas/_nexus-shacl-schemas.html","text":"","title":"Namespaces and Context"},{"location":"/docs/shacl-tutorial/nexus-kg-schemas/_nexus-shacl-schemas.html#namespaces-and-context","text":"\"@context\" : {\n \"class\" : {\n \"@id\" : \"sh:class\",\n \"@type\" : \"@id\"\n },\n \"rootClass\" : {\n \"@id\" : \"shext:rootClass\",\n \"@type\" : \"@id\"\n },\n \"path\" : {\n \"@id\" : \"sh:path\",\n \"@type\" : \"@id\"\n },\n \"qualifiedValueShape\" : {\n \"@id\" : \"sh:qualifiedValueShape\",\n \"@type\" : \"@id\",\n \"@container\" : \"@list\"\n },\n \"qualifiedValueShapesDisjoint\" : {\n \"@id\" : \"sh:qualifiedValueShapesDisjoint\",\n \"@type\" : \"xsd:boolean\"\n },\n \"qualifiedMinCount\" : {\n \"@id\" : \"sh:qualifiedMinCount\",\n \"@type\" : \"xsd:integer\"\n },\n \"qualifiedMaxCount\" : {\n \"@id\" : \"sh:qualifiedMaxCount\",\n \"@type\" : \"xsd:integer\"\n },\n \"maxCount\" : {\n \"@id\" : \"sh:maxCount\",\n \"@type\" : \"xsd:integer\"\n },\n \"minCount\" : {\n \"@id\" : \"sh:minCount\",\n \"@type\" : \"xsd:integer\"\n },\n \"minInclusive\" :\"sh:minInclusive\",\n \"maxInclusive\" :\"sh:maxInclusive\",\n \"maxExclusive\" :\"sh:maxExclusive\",\n \"minExclusive\" :\"sh:minExclusive\",\n \"in\" : {\n \"@id\" : \"sh:in\",\n \"@container\" : \"@list\"\n },\n \"imports\" : {\n \"@id\" : \"owl:imports\",\n \"@type\" : \"@id\",\n \"@container\" : \"@set\"\n },\n \"datatype\" : {\n \"@id\" : \"sh:datatype\",\n \"@type\" : \"@id\"\n },\n \"description\" : \"sh:description\",\n \"name\" : \"sh:name\",\n \"nodeKind\" : {\n \"@id\" : \"sh:nodeKind\",\n \"@type\" : \"@id\"\n },\n \"node\" : {\n \"@id\" : \"sh:node\",\n \"@type\" : \"@id\"\n },\n \"property\" : {\n \"@id\" : \"sh:property\",\n \"@type\" : \"@id\",\n \"@container\" : \"@set\"\n },\n \"targetClass\" : {\n \"@id\" : \"sh:targetClass\",\n \"@type\" : \"@id\"\n },\n \"targetObjectsOf\" : {\n \"@id\" : \"sh:targetObjectsOf\",\n \"@type\" : \"@id\"\n },\n \"targetSubjectsOf\" : {\n \"@id\" : \"sh:targetSubjectsOf\",\n \"@type\" : \"@id\"\n },\n \"isDefinedBy\" : {\n \"@id\" : \"http://www.w3.org/2000/01/rdf-schema#isDefinedBy\",\n \"@type\" : \"@id\"\n },\n \"shapes\" : {\n \"@reverse\" : \"http://www.w3.org/2000/01/rdf-schema#isDefinedBy\",\n \"@type\" : \"@id\",\n \"@container\" : \"@set\"\n },\n \"or\" : {\n \"@id\" : \"sh:or\",\n \"@type\" : \"@id\",\n \"@container\" : \"@list\"\n },\n \"and\" : {\n \"@id\" : \"sh:and\",\n \"@type\" : \"@id\",\n \"@container\" : \"@list\"\n },\n \"xone\" : {\n \"@id\" : \"sh:xone\",\n \"@type\" : \"@id\",\n \"@container\" : \"@list\"\n },\n \"not\" : {\n \"@id\" : \"sh:not\",\n \"@type\" : \"@id\",\n \"@container\" : \"@list\"\n },\n \"lessThan\": {\n \"@id\" : \"sh:lessThan\",\n \"@type\" : \"@id\"\n },\n \"hasValue\" :\"sh:hasValue\",\n \"owl\" : \"http://www.w3.org/2002/07/owl#\",\n \"rdf\" : \"http://www.w3.org/1999/02/22-rdf-syntax-ns#\",\n \"rdfs\" : \"http://www.w3.org/2000/01/rdf-schema#\",\n \"xsd\" : \"http://www.w3.org/2001/XMLSchema#\",\n \"sh\" : \"http://www.w3.org/ns/shacl#\",\n \"shext\" : \"http://www.w3.org/ns/shacl/ext#\",\n \"schema\" : \"http://schema.org/\",\n\n }\nWithin this document, the following prefix mappings are used:\nPrefix Name Namespace sh http://www.w3.org/ns/shacl# rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs http://www.w3.org/2000/01/rdf-schema# owl http://www.w3.org/2002/07/owl# xsd http://www.w3.org/2001/XMLSchema# prov http://www.w3.org/ns/prov# shext http://www.w3.org/ns/shacl/ext# schema http://schema.org/ bbp https://bbp-nexus.epfl.ch/ns#\nNote that the 'bbp' namespace is used in this document as an example namespace.\nBy convention all shapes defined in a SHACL schema are prefixed by this.\nPrefix Name Namespace this {endpoint}/schemas/{org}/{domain}/{schema_name}/{version}/shapes/\nTo improve readability and to simplify the examples, the SHACL context described in the right is used for all the SHACL JSON-LD serialization presented in this document. This default context is only related to the SHACL vocabulary and should be used in all schemas. Since writing a SHACL schema almost always required to use a domain vocabulary, domain context can be added when needed. In all cases, the context object is omitted in the examples below. It needs to be added to make the examples work.","title":"Namespaces and Context"},{"location":"/docs/shacl-tutorial/nexus-kg-schemas/_nexus-shacl-schemas.html#shacl-schemas","text":"{\n \"@id\" : \"{endpoint}/schemas/{org}/{domain}/{schema_name}/{version}/\",\n \"@type\":\"owl:Ontology\",\n \"shapes\" : [{\n \"@id\" : \"this:{shapeName}\",\n \"@type\":\"sh:Shape\"\n },{\n \"@id\" : \"this:{anotherShapeName}\",\n \"@type\":\"sh:Shape\"\n }]\n}\nIn Nexus Knowledge Graph (KG), a schema:\nis identified by a URI consistent with the following pattern: {endpoint}/schemas/{org}/{domain}/{schema_name}/{version}/, is an ontology: it has owl:Ontology as type defines a collection of a collection of shapes; the objects in the shapes array. The ‘shapes’ key is defined as a reverse property of rdfs:isDefinedBy\nNote that the W3C SHACL recommendation only defines SHACL shapes and doesn't define particular ways of wrapping them together.\nFrom this point, a Nexus KG schema will be indifferently referred to as a SHACL schema or just schema.\nWrapping shapes together in a schema allows us to (among other things):\ngive an identifier to a collection of shapes attach annotations to the schema import vocabularies and/or ontologies import other schemas for reuse purpose\nA schema can then be seen here as an envelop for shapes exchange.","title":"SHACL schemas"}]} \ No newline at end of file