buda-base / owl-schema

BDRC Ontology Schema
11 stars 2 forks source link

cleanup #113

Open eroux opened 5 years ago

eroux commented 5 years ago

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:

- core/
- admin/
- ext/
   - toberemoved/
   - bdrc/

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?

xristy commented 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?

eroux commented 5 years ago

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.

xristy commented 5 years ago

./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.

eroux commented 5 years ago

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?

xristy commented 5 years ago

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

eroux commented 5 years ago

I'm fine with removing the properties in the toberemoved namespace and associated triples in our data yes.

xristy commented 5 years ago

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

xristy commented 5 years ago

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.

xristy commented 5 years ago

Is ./i18n still needed?

eroux commented 5 years ago

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

xristy commented 5 years ago

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.

xristy commented 5 years ago

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.

eroux commented 5 years ago

great! that's quite a nice feature I think