Open eroux opened 5 years ago
I started the cleanup per your proposal. I want to review some of the items that are now in ./ext. I don't know what you envision putting in .ext/bdrc - lang-tags.md, catalog-v001.xml?
does context.jsonld need to move? Are there configs in lds-pdi or library that need the path of context.jsonld if it is moved?
For now I see auth.ttl moving to ./admin.
I'm not sure what changes for imports in global.ttl are needed (if any) when moving the files like bdo.ttl to ./core and auth.ttl to ./admin.
Should global.ttl remain at the top-level?
Thanks! ext/bdrc/
would be where the properties in the http://purl.bdrc.io/ontology/ext/bdrc
would live, we don't have anything there yet, so let's not confuse things now... it's kind of strange to have the external things being in ext/
, in my mind it corresponds to http://purl.bdrc.io/ontology/ext/
in which ext
is extension, not external...
For now we have only one context, but if we start to have several (which will probably happen but I'm not sure yet) they would probably be well moved into a context/
directory. lds-pdi
has the path of context.jsonld yes, you can see it in this search towards the bottom
As long as global.ttl
continues to work in Protege (like global.owl
was) and TopQuadrants that's good, I don't know all the subtleties without testing.
./ext/toberemoved threw me off. Perhaps:
- global.ttl
- core/
- bdo.ttl
- admin/
- auth.ttl
- ext/
- bdrc/
- bdo.owl.ttl
- bdo.shapes.ttl
I think bdrc-ut.ttl can be removed since it was an experiment that Marc added about 3 weeks ago
I suppose we could change the name bdo.ttl
to bdo-core.ttl
and leave it at the top-level w/ gobal.ttl
.
Here's the reasoning I made. We have the following namespaces:
http://purl.bdrc.io/ontology/core/
http://purl.bdrc.io/ontology/admin/
http://purl.bdrc.io/ontology/toberemoved/
http://purl.bdrc.io/ontology/ext/auth/
which, I believe, should be reorganized into
http://purl.bdrc.io/ontology/core/
http://purl.bdrc.io/ontology/admin/
http://purl.bdrc.io/ontology/ext/toberemoved/
http://purl.bdrc.io/ontology/ext/auth/
http://purl.bdrc.io/ontology/ext/bdrc/
if we remove the http://purl.bdrc.io/ontology/
from these, we get:
core/
admin/
ext/toberemoved/
ext/auth/
ext/bdrc/
which looks like a directory structure. So my idea was to materialize this directory structure in the repository. This would be nice since now we have 3 files each time:
(.rdfs).ttl
.owl.ttl
.shacl.ttl
so my thought was to have these three files in each directory, something like
core/
bdo.ttl
bdo.owl.ttl
bdo.shacl.ttl
admin/
adm.ttl
adm.owl.ttl
adm.shacl.ttl
...
Now, that was just an idea like that I'm not very attached to it, but I thought it would have some benefits in terms of maintainability and coherence. Maybe you can have an alternative file hierarchy in mind?
Based on your initial reasoning I'd think that ./toberemoved would follow the namespace rather than ./ext/toberemoved unless we change the namespace, but I don't see the original tbr namespace as an extension.
In fact we can just schedule to remove the tbr items or reposition them as active components of the overall ontology somewhere if some are still to be retained (which I doubt). The idea initially was to preserve tbr items in the ontology until we resolved how to migrate the original XML so if we're done with that phase of development we should just delete the chaff from bdo.ttl and not memorialize it further.
As for other dir re-structure I'll do some tests and see what we can do. In XQuery the import allows the identifying the namespace and a local file location
I'm fine with removing the properties in the toberemoved namespace and associated triples in our data yes.
I'm taking that the primary concern is to keep the actual ontology files that we are wanting to be easily identifiable and usable by other parties somewhat separate from other supporting files like our constraint files. If bdo.owl.ttl
and bdo.shacl.ttl
are considered relevant to 3rd-party users then certainly it makes sense to keep them with the files they constrain. I'm fine for now putting thses two files in ./core/
along w/ bdo.ttl
Based on your initial reasoning I'd think that ./toberemoved
would follow the namespace rather than ./ext/toberemoved
unless we change the namespace, but I don't see the original tbr
namespace as an extension.
Also I do not see any occurrences of the ./ontology/ext/bdrc
namespace. We can add that later when there's content.
Similarly when the ./ontology/admin
namespace is refactored then ./admin/
can be added.
I'm putting a ./toberemoved
dir at top-level temporarily while I work on the re-org.
Is ./i18n
still needed?
there's nothing in ext/bdrc
yes, no need to create it before we add anything here. I think the owl.ttl
and shacl.ttl
are fine with the others, as long as we document what they are. We can remove the i18n for the moment yes. I'm also wondering if we should perhaps move the individuals into their own file? I think that would make sense... but we can do that later
I'm done for today. The global.ttl doesn't work in Protégé or TBC by itself. If the imported files are in the same project/dir tree containing the TBC properly loads and the Protégé doesn't.
I've sent an email to composersupport to see what I'm doing wrong.
Curls like:
curl -v -H "Accept: text/turtle" http://purl.bdrc.io/ontology/ext/auth/
and
curl -v -H "Accept: text/turtle" http://purl.bdrc.io/ontology/core/
now work as expected.
Also I just tested loading global.ttl
from github via Protégé and it works fine - owing to @MarcAgate updates.
I loaded the file from a clean dir tree without any other *.ttl
anywhere in sight so it had to resolve against the web, i.e., ldspdi, and use the URL of the doc as the baseURI.
great! that's quite a nice feature I think
Here's a proposal for a cleanup.
First: what are
.tbc
files? they seem to be composer-specific, so I propose to remove them from the repo (as well as the.project
file). This doesn't mean that you cannot have it on your machine, it just means that it's not part of the files in this repo.I propose we convert all our .owl files into .ttl instead of having a multitude of files with barely distinguishable names.
Because we moved from a basically one file system to a system with many different ontologies, each encoded in several files, I propose we move to a structure based on directories:
I also propose we remove the
resources/
directory which doesn't look very helpful and contains data that might be a bit outdated or irrelevant.Finally, the doc should be updated accordingly.
Wdyt?