search

buda-base / owl-schema

BDRC Ontology Schema
11 stars 2 forks source link

accessing scheme graph #166

Closed eroux closed 4 years ago

eroux commented 4 years ago

Looking at https://github.com/buda-base/owl-schema/blob/abstractworks/schemes/ContentMethodScheme.ttl I'm not entirely sure how to get the graph of the scheme? It seems bdr:ContentMethodScheme is both a skos:ConceptScheme and an owl:Ontology (or maybe the owl:Ontology is the one with the / at the end? I'm not sure it's a very good way to distinguish between two different things...), but when I go to

I'm not sure what the best way to handle the situation is, but we clearly need:

I'm not opposed to having the same uri for the graph/ontology and the skos:ConceptScheme, but I'm not really convinced by differentiating them with just a / at the end. @xristy can you clean that up a little bit? Once it's done, @MarcAgate can you handle it it ldspdi? It's really in order to prepare the work for the editor so it's quite high priority

eroux commented 4 years ago

caveat: the translations need to be in the graph too... I'm not opposed to copy/pasting the triples in the file

xristy commented 4 years ago

I'll take look at this later this afternoon.

xristy commented 4 years ago

I think I made an error putting the scheme in the bdr namespace. So I changed the baseURI and @prefix ContentMethodScheme from http://purl.bdrc.io/resource/ContentMethodScheme/ to http://purl.bdrc.io/ontology/schemes/ContentMethodScheme/ and I updated the ont-policy.rdf accordingly.

This should have put the ContentMethodScheme into an ontology namespace rather than the bdr namespace. This is the same pattern as http://purl.bdrc.io/ontology/types/Gender.ttl and other types.

However, after I committed these changes the refs to http://purl.bdrc.io/ontology/schemes/ContentMethodScheme/ and http://purl.bdrc.io/ontology/schemes/ContentMethodScheme.ttl simply return {} indicating that ldspdi didn't find anything.

Maybe @MarcAgate could take a look at ldspdi and see whether the commit updated the ontology in fuseki or whether there's something else happening.

The intent of the pattern I'm using for the concept schemes is to retain the same instances when they were just plain types and add a parallel organization using the skos vocabulary, so I don't see why the change I made didn't work w/ ldspdi which I don't think has any special treatment for the skos:topConceptOf and skos:broader and skos:narrower properties; and so ldspdi should just have treated the ContentMethodScheme as it does with Gender type.

I don't actually understand your comment about differentiating with a / at the end or not.

MarcAgate commented 4 years ago

Well, we have to talk about those things. Right now, we have two instances of ldspdi working with two branches of the ontology. This is quite messy and complex. For instance, there is no way you can see changes in owl-schema/abstractWorks on purl.bdrc.io despite the fact that you might have created ontologies with purl.bdrc.io/ontology/xxx like urls.

At this point, given the numerous ontologies, given the underlying import mechanism, given the webhooks, the two different datasets, and so on, and given the possible text/turtle and/or text/html output for any ontology or ontology resource, it requires quite sometime and reflexion to manage this properly once we get it working in all cases. I'll try to tackle this issue on wednesday (it seems like I found a way to deal with this issue when processing the ont-policy file of editor-templates -the shach shapes-). More to come.

eroux commented 4 years ago

URLs

Yes, for one URI in our ontology (like http://purl.bdrc.io/resource/P1583), we have two representations:

I don't think it's messy, I think we just need to be aware of this and careful. Marc, if you have a more simple solution that this, I'm all ears. I can't see the complexity in our system but if there are even more simple solutions that's good.

Chris, this is why you should test http://ldspdi-dev.bdrc.io/ontology/schemes/ContentMethodScheme.ttl not http://purl.bdrc.io/ontology/schemes/ContentMethodScheme.ttl for the dev branch. Note that this doesn't work neither.

Slash

Now that you have moved the scheme to its own namespace, it's fine.

Different schemes?

I'm a bit hesitant to have the schemes that are directly linked with the ontology (gender, material, etc.) in the same git repo / namespace as our taxonomies for tradition, topics, genres, etc. Why not having

wdyt @xristy ?

xristy commented 4 years ago

The temporary links like http://ldspdi-dev.bdrc.io/ontology/schemes/ContentMethodScheme.ttl do work now. There's some hiccup in ldspdi-dev github triggered update that @MarcAgate is looking into.

The html links like http://ldspdi-dev.bdrc.io/ontology/schemes/FEMCScheme, currently return

This page is disabled for that server

because as @MarcAgate indicates

it is disabled because there's no easy way to map real uri inside the model to fake uri for service on a server different from purl.bdrc.io

which is part of the messiness of substituting ldspdi-dev.bdrc.io for purl.bdrc.io

eroux commented 4 years ago

ok thanks, that looks good! What do you think of moving the taxonomies in separate repos? in this new repo we may not actually have to use the ontology pattern of ont-policy.rdf, etc. we can just have the usual pattern with a graph that is synchronized by gittodb...

xristy commented 4 years ago

I need to think through the separate repos.

eroux commented 4 years ago

ok, I think it's in place now

xristy commented 4 years ago

Edit: I intended to publish this yesterday evening.

For now, the abstractworks branch now has schemes/core and schemes/taxonomy.

The evolving branch has all the roles and types in abstractworks branch schemified. I will place all of the schemes into schemes/core except for:

ChineseMonasticScheme.ttl
ContentProviderScheme.ttl
FEMCScheme.ttl
SubjectScheme.ttl
TraditionScheme.ttl

The SubjectScheme.ttl is the schemification of the O9TAXTBRC201605 taxonomy outline.

The previoustype/taxonomy.ttl no longer exists since it is replaced by uniform use of skos:ConceptScheme.

I'm not sure of the benefits of separate repos and in particular for the schemes/core which organize types for the core ontology.

I've tried for now to make an incremental change that should not be wasted motion.

eroux commented 4 years ago

excellent, thanks!

I think the main benefit of splitting is that keeps the ontology as a self-contained reusable thing on one repo. The topic taxonomy makes no sense without the topic records which are specific to bdrc and are stored elsewhere so I tend to see that as being outside of the ontology... wdyt?