Have you considered having the prefix be distinct from the service's homepage, and instead having it be a separate URI that could in future reference documentation for the ontology? We do this in the Legislation ontology by having the prefix as http://www.legislation.gov.uk/def/legislation/, which is also its documentation page. (We also have subresources of that page be individual pages with information about specific properties or classes, e.g. /def/legislation/EnglandAct is its own page)
I think having both : and caselaw: map to the caselaw prefix in the ontology files is unnecessarily confusing. Please would you consider only using one or the other, not both?
I think we should probably have a Treaty class in the Legislation ontology, it seems a little silly for caselaw to have to create a subclass of our Item class (which I'm not sure is the right class to subclass anyway) because we're lacking the required class in our own ontology. What do you think @CathTabone?
3: Un-necessary(?) and sometimes incorrect redefinitions of things defined elsewhere
This isn't the description as it appears in our ontology. The correct description is "A distinct, numbered item, which may contain one or more items of legislation."
Is it necessary to redeclare all the external classes and properties you use from other ontologies? Is it possible to import the external ontologies or is that not a workable solution? (The same applies for the properties redefined in the xsd, rdf, dct and other external namespaces)
4: Mismatch between IRIs for classes between the two ontology files
The IRI http://caselaw.nationalarchives.gov.uk/#AdjudicatingBody doesn't appear in caselaw.ttl. The IRI for the class AdjudicatingBody in that file is http://caselaw.nationalarchives.gov.uk/AdjudicatingBody (or caselaw:AdjudicatingBody as it appears in its abbreviated form). The caselaw: prefix is defined and used in this file, so was there a reason to not use it to refer to these classes?
5: Inconsistent naming conventions and awkward class names
Do you think it would be possible to make the longer court names a bit shorter and less awkward to type by hand by removing the extraneous punctuation and/or abbreviating part or all of the name? From experience I think this would make it easier to refer to the courts when authoring SPARQL queries, both in typing the names out and also recalling them from memory rather than having to copy-paste from elsewhere. Would you consider putting the full names in another property like caselaw:name? (We do this in the Legislation ontology, for example "Composite Act of the English Parliament" becomes CompositeEnglandAct with the full name in an rdfs:label)
I can't find any other reference to Privy_Council_1937_1978. Is this intentionally missing/a known issue to correct?
The territorialJurisdiction is https://www.wikidata.org/wiki/Q244 which refers to Barbados, but the actual jurisdiction of the JCPC seems to be much broader. Was your intention to put in the other territories later, or have I misunderstood what you're expressing here?
Do you intend to give other courts a territorialJurisdiction property? It seems like it might be quite complex to model the jurisdictions of the various courts (for example the Supreme Court is apparently the final court of appeal for all UK civil cases, but for criminal cases from E+W+NI only). Do you have a plan for how you will extend the jurisdiction modelling to cover other courts, or do you not intend to do so?
The name of this court isn't actually "Privy Council". Might it be better to have the class name reflect that its actual name is "Judicial Committee of the Privy Council" (perhaps with an abbreviation like JCPC re the issue in section 5 above)?
7: Adjudicating body epochs and the startDate and endDate properties
These seem to me odd properties to borrow from the Legislation ontology—I generally think it's best to reuse features from generic ontologies where possible, in the hope that these will be better designed and that the knowledge users gain by learning them can be used elsewhere. I think we probably implemented these properties in the Legislation ontology due to lack of a generally available ontology for modelling time when we implemented it. However, there is now OWL-Time, a W3 ontology authored by the Met Office and CSIRO that has already been made a W3 recommendation (see the original version with W3 recommendation status here) and has many implementations. Would you consider using OWL-Time instead of reusing our properties? (@CathTabone I don't know whether you suggested caselaw reuse these properties?)
Do you intend for all courts to have epochs, so that they too can have a startDate property?
Also, do you think that these properties express (indirectly or directly) the same information as the caselaw:yearCourtEstablished and caselaw:yearCourtAbolished properties defined here?
What entity do you propose to attach these "reference" classes to? Would you create a new IRI in your own namespace to refer to, say, a journal article, or would you reuse an existing public URI for the resource (e.g. [] caselaw:cites <https://doi.org/10.1177/00258024221111908> . <https://doi.org/10.1177/00258024221111908> rdf:type caselaw:JournalArticle for citing a journal article like this)?
I don't think you've used this property yet. I'm not clear it's necessary, as presumably you could instead query for courts where the caselaw:yearCourtAbolished property is present/absent (or where the court does/does not has an epoch without an end date). However, some redunancy can be helpful to make authoring queries easier and running them more performant, so I don't have a strong opinion about whether it should be present.
I spoke briefly to @CathTabone about the Treaty class issue in point 2—she said we probably do want it in the Legislation ontology.
Some questions:
What data source/method is the enrichment process using to identify treaties? Is there a list, or it is doing pattern matching of some kind?
Will the enrichment process capture references to legislation to which the UK was never a signatory? If yes, that maybe slightly complicates the modelling.
My feedback on the ontology:
1: The prefixes
https://github.com/nationalarchives/ds-caselaw-data-enrichment-service/blob/f32a25a10f4c65375f3ca6b936541507c5bd2c50/ontology/ontology/caselaw.ttl#L1
http://www.legislation.gov.uk/def/legislation/
, which is also its documentation page. (We also have subresources of that page be individual pages with information about specific properties or classes, e.g./def/legislation/EnglandAct
is its own page):
andcaselaw:
map to the caselaw prefix in the ontology files is unnecessarily confusing. Please would you consider only using one or the other, not both?2: Treaty class
https://github.com/nationalarchives/ds-caselaw-data-enrichment-service/blob/f32a25a10f4c65375f3ca6b936541507c5bd2c50/ontology/ontology/caselaw.ttl#L486-L487
I think we should probably have a
Treaty
class in the Legislation ontology, it seems a little silly for caselaw to have to create a subclass of ourItem
class (which I'm not sure is the right class to subclass anyway) because we're lacking the required class in our own ontology. What do you think @CathTabone?3: Un-necessary(?) and sometimes incorrect redefinitions of things defined elsewhere
https://github.com/nationalarchives/ds-caselaw-data-enrichment-service/blob/f32a25a10f4c65375f3ca6b936541507c5bd2c50/ontology/ontology/caselaw.ttl#L496-L498
This isn't the description as it appears in our ontology. The correct description is "A distinct, numbered item, which may contain one or more items of legislation."
Is it necessary to redeclare all the external classes and properties you use from other ontologies? Is it possible to import the external ontologies or is that not a workable solution? (The same applies for the properties redefined in the
xsd
,rdf
,dct
and other external namespaces)4: Mismatch between IRIs for classes between the two ontology files
https://github.com/nationalarchives/ds-caselaw-data-enrichment-service/blob/f32a25a10f4c65375f3ca6b936541507c5bd2c50/ontology/ontology/uk-court-system.ttl#L17-L18
The IRI
http://caselaw.nationalarchives.gov.uk/#AdjudicatingBody
doesn't appear incaselaw.ttl
. The IRI for the classAdjudicatingBody
in that file ishttp://caselaw.nationalarchives.gov.uk/AdjudicatingBody
(orcaselaw:AdjudicatingBody
as it appears in its abbreviated form). Thecaselaw:
prefix is defined and used in this file, so was there a reason to not use it to refer to these classes?5: Inconsistent naming conventions and awkward class names
https://github.com/nationalarchives/ds-caselaw-data-enrichment-service/blob/f32a25a10f4c65375f3ca6b936541507c5bd2c50/ontology/ontology/uk-court-system.ttl#L26-L33
Is there a reason some class names have underscores in and some don't?
https://github.com/nationalarchives/ds-caselaw-data-enrichment-service/blob/f32a25a10f4c65375f3ca6b936541507c5bd2c50/ontology/ontology/uk-court-system.ttl#L174-L177
Do you think it would be possible to make the longer court names a bit shorter and less awkward to type by hand by removing the extraneous punctuation and/or abbreviating part or all of the name? From experience I think this would make it easier to refer to the courts when authoring SPARQL queries, both in typing the names out and also recalling them from memory rather than having to copy-paste from elsewhere. Would you consider putting the full names in another property like
caselaw:name
? (We do this in the Legislation ontology, for example "Composite Act of the English Parliament" becomesCompositeEnglandAct
with the full name in anrdfs:label
)6: Questions about Privy Council
https://github.com/nationalarchives/ds-caselaw-data-enrichment-service/blob/f32a25a10f4c65375f3ca6b936541507c5bd2c50/ontology/ontology/uk-court-system.ttl#L123-L127
Privy_Council_1937_1978
. Is this intentionally missing/a known issue to correct?territorialJurisdiction
is https://www.wikidata.org/wiki/Q244 which refers to Barbados, but the actual jurisdiction of the JCPC seems to be much broader. Was your intention to put in the other territories later, or have I misunderstood what you're expressing here?territorialJurisdiction
property? It seems like it might be quite complex to model the jurisdictions of the various courts (for example the Supreme Court is apparently the final court of appeal for all UK civil cases, but for criminal cases from E+W+NI only). Do you have a plan for how you will extend the jurisdiction modelling to cover other courts, or do you not intend to do so?7: Adjudicating body epochs and the
startDate
andendDate
propertieshttps://github.com/nationalarchives/ds-caselaw-data-enrichment-service/blob/f32a25a10f4c65375f3ca6b936541507c5bd2c50/ontology/ontology/caselaw.ttl#L334-L344
startDate
property?caselaw:yearCourtEstablished
andcaselaw:yearCourtAbolished
properties defined here?8:
OnlineReference
and other reference classeshttps://github.com/nationalarchives/ds-caselaw-data-enrichment-service/blob/f32a25a10f4c65375f3ca6b936541507c5bd2c50/ontology/ontology/caselaw.ttl#L465-L467
What entity do you propose to attach these "reference" classes to? Would you create a new IRI in your own namespace to refer to, say, a journal article, or would you reuse an existing public URI for the resource (e.g.
[] caselaw:cites <https://doi.org/10.1177/00258024221111908> . <https://doi.org/10.1177/00258024221111908> rdf:type caselaw:JournalArticle
for citing a journal article like this)?9:
subjectMatterJurisdiction
https://github.com/nationalarchives/ds-caselaw-data-enrichment-service/blob/f32a25a10f4c65375f3ca6b936541507c5bd2c50/ontology/ontology/caselaw.ttl#L207-L209
You've not specified a range for this property. Do you have a plan for what entities you'll put at the other end and what they might look like?
10:
current
https://github.com/nationalarchives/ds-caselaw-data-enrichment-service/blob/f32a25a10f4c65375f3ca6b936541507c5bd2c50/ontology/ontology/caselaw.ttl#L240-L244
I don't think you've used this property yet. I'm not clear it's necessary, as presumably you could instead query for courts where the
caselaw:yearCourtAbolished
property is present/absent (or where the court does/does not has an epoch without an end date). However, some redunancy can be helpful to make authoring queries easier and running them more performant, so I don't have a strong opinion about whether it should be present.