RDF source and serialization

[eroux]

This is really a question about what happens when the URL http://purl.bdrc.io/ontology/shapes/core/PersonShape is fetched. For instance, does it return:

• just the triples associated with bds:PersonShape or also those associated with the "subshapes"?
• the triples included in the file?
• the content of a graph? with what URI?

[eroux]

I think we could operate in a way similar to the ontology graph/files: we would have:

• http://purl.bdrc.io/ontology/shapes/core/ return all the triples in all the files in the shapes/core/ files of this repo (with the commit as ETag, etc. just like the ontology), this is what we would call the shapes graph
• http://purl.bdrc.io/ontology/shapes/core/Person would return the result of a sparql query (a simple describe I think) on the shapes graph

@MarcAgate @xristy what do you think?

[xristy]

I think the URL interpretations work with the proviso that imports need to be done for example when retrieving http://purl.bdrc.io/ontology/shapes/core/Person since there will be imports of shape files such as person.event.shapes.ttl which in turn (at least at the moment) imports event.shapes.ttl.

I'm thinking that the client will need the collection of person.shapes triples to construct and validate the forms elements associated with a Person profile. The profiles, as I'm thinking of them, will be lists of named property shapes to be instantiated or or filled in from an existing resource. For example, a BasicPersonProfile might consist of something like:

bform:personName1 xx:hasFormElem bds:PersonShape-personName ;
  sh:path :personName/:personNameType ;
  sh:value bdr:PersonNameTypePrimaryName ;
.
bform:personName2 xx:hasFormElem bds:PersonShape-personName ;
  sh:path :personName/:personNameType ;
  sh:value bdr:PersonNameTypePersonalName ;
.
bform:personGender xx:hasFormElem bds:PersonShape-gender ;
.

Would display a form with elements for the primary and personal names and a form element for the gender. The basic appearance of the elements is described by the shapes indicating the dash:editor to use and so on

Alternatively I suppose, there could a service so that just the shapes referred to in a Profile would be sent to the client.

[eroux]

hmmm ok... can you make a concrete proposal for the URLs and the RDF triples they produce?

[xristy]

Currently each shape file is defined as an owl:ontology with baseURI such as:

http://purl.bdrc.io/ontology/shapes/core/PersonShapes/

A shapes ontology may import dependent shape ontologies; such as:

PersonShapes:
  a owl:Ontology ;
  owl:imports <http://datashapes.org/dash> ;
  owl:imports bdo: ;
  owl:imports <http://purl.bdrc.io/ontology/shapes/core/PersonEventShapes/> ;
  owl:versionInfo "SHACL constraints for Person" ;
.

I will add an ont-policy.rdf to editor-templates and we'll need to have a convention for identifying the intended top level list of shapes ontologies that constitute entry-points into the resources that are expected to be created and updated.

There will need to be some sort of Profiles namespace(s) that could perhaps serve as the entry-points.

Given all this I think that the baseURIs of the shapes ontologies are the appropriate URLs to consider and when a GET is requested on such a URL, e.g., http://purl.bdrc.io/ontology/shapes/core/PersonShapes/, then the set of triples resulting from the associated file and its imports should be the returned graph -- as w/ ont-policy.rdf in owl-schema we will have:

<processImports rdf:datatype="&xsd;boolean">true</processImports>

[eroux]

ok yes, why not. Once there's an ont-policy.rdf file we can start implementing the API to get the RDF... @xristy can you look into that in priority so that then @MarcAgate can work on it?

[xristy]

I've committed an initial editor-templates/ont-policy.rdf

[eroux]

Excellent thanks!