Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

individualToSadl with external models #798

Open
agabaldon opened this issue Sep 27, 2021 · 13 comments
Open

individualToSadl with external models #798

agabaldon opened this issue Sep 27, 2021 · 13 comments

Comments

@agabaldon
Copy link
Collaborator

I noticed that when OwlToSadl.individualToSadl is called with the URI of an instance defined in an external model (imported owl file), it returns null. But if the instance is defined in an imported sadl model, it does return the instance. How can we modify individualToSadl to return instances from an external model?

@crapo
Copy link
Collaborator

crapo commented Sep 29, 2021

@agabaldon , can you provide a minimal use case? Is this call from ASKE or CsvImporter?

@agabaldon
Copy link
Collaborator Author

agabaldon commented Sep 30, 2021

It came from a "What is [instance]?" query in ASKE. When [instance] is defined in a SADL file, we get an answer. But if [instance] is defined in an external model, we get null. There wasn't anything special about the SADL file and the external model I used, so you can probably reproduce it with any ones, but I'll make a minimal use case.

@crapo
Copy link
Collaborator

crapo commented Sep 30, 2021

@agabaldon , I switched to SADL development and ASKE master branches. Using the project ASKE_P2 (as I have it, no idea how current it is), I created this dialog:
image
This appears to not have the fix pushed a while back to not treat "CM:" statements as declarations, but beyond that it clearly found the individual in the external OWL file. I don't know if it went through OwlToSadl.individualToSadl, but I'm wondering if my code base is different than yours or what might be happening?

@agabaldon
Copy link
Collaborator Author

Right. The problem is something else. The owl file I used has instances defined by statements like:
<MYClass rdf:about="http://semtk.research.ge.com/generated#bb5275db-a56e-40c8-b814-112f3f08090d"> ... </MYClass>

and I was querying "What is bb5275db-a56e-40c8-b814-112f3f08090d?' and of course the query was translated using the the base model prefix and the instance is not found.

Is there a way to use a full URI in a query? For example, to write "What is 'http://semtk.research.ge.com/generated#bb5275db-a56e-40c8-b814-112f3f08090d'?

Or maybe a better way to do this is to first define a new namespace prefix, for example,

prefix "http://semtk.research.ge.com/generated" generated. //similar to an import statement but just defines a prefix

then write the query as "What is generated:bb5275db-a56e-40c8-b814-112f3f08090d?"
In other words, add a prefix definition statement to the language.

@crapo
Copy link
Collaborator

crapo commented Sep 30, 2021

Doesn't the OWL model that has the statement
'''
<MYClass rdf:about="http://semtk.research.ge.com/generated#bb5275db-a56e-40c8-b814-112f3f08090d"> ... </MYClass>
'''
define prefixes for the namespaces used within it? I would expect, if it were in RDF/XML format something like...
'''
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:generated="http://semtk.research.ge.com/generated#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
'''
I would expect the identifying of a prefix to go with an internal namespace not the same as the model's base URI to be the responsibility of the external model.

@crapo
Copy link
Collaborator

crapo commented Sep 30, 2021

A URI in the SADL grammar is a quoted string, which is validated not by the grammar but by validation code. To allow a URI to be directly used everywhere that a SadlResource is allowed would be a major complication to the grammar. It would be more feasible to add a new SADL statement type that allowed additional prefixes to be defined other than those associated with model base URIs as identified in the import statement. However, there may be some surprises. SADL has a somewhat pervasive assumption that a single OWL model (file) has a single namespace for concepts defined within it.

@agabaldon
Copy link
Collaborator Author

I tried adding the line xmlns:generated="http://semtk.research.ge.com/generated#" to the owl file but SADL doesn't recognize generated:bb5275db-a56e-40c8-b814-112f3f08090d

@agabaldon
Copy link
Collaborator Author

"SADL has a somewhat pervasive assumption that a single OWL model (file) has a single namespace for concepts defined within it." This assumption makes sense. The only case I think you'd want to violate it is if you wanted to split instance definitions into multiple graphs/owl files. But in that case I imagine the imports would include all the necessary namespace prefixes. It doesn't make sense to import instances that don't belong to any declared namespace. The owl file I was using basically has instances that belong to a graph that I don't have (http://semtk.research.ge.com/generated).

@crapo
Copy link
Collaborator

crapo commented Sep 30, 2021

I didn't expect that adding that prefix definition by itself would work, but it's possible that it could be made to work. If I understand correctly, there is enough information in the OWL file to know that bb5275db-a56e-40c8-b814-112f3f08090d is an instance of class MyClass, using your statement above. I have encountered other OWL files where definitions in multiple namespaces were included in a single OWL file. That's a significant problem when trying to import as a SADL model, because of the assumption of one model one namespace. However, it might not be showstopper for importing an external OWL file. Would you like to share the OWL file in question, with the added prefix definition, and I'll take a look at it?

@crapo
Copy link
Collaborator

crapo commented Dec 8, 2021

@agabaldon , this is from my perspective waiting for you to share the OWL file, if you can do so, so that I can explore whether this might be made to work for imported external OWL models, even though it appears irresolvable for importing OWL files into SADL models. WRT the latter, we could take the approach of creating multiple SADL files from a single OWL file import, which might be a solution to importing into SADL problem.

@agabaldon
Copy link
Collaborator Author

The file was from an internal project. I think we can close this for now or keep it as a "desired feature" for the future.

@crapo
Copy link
Collaborator

crapo commented Jan 11, 2022

@agabaldon , I'd like to keep it open. It would be nice to have a minimal case that reproduces the problem. Perhaps sometime you could generate such a use case?

@agabaldon
Copy link
Collaborator Author

Yeah, sounds good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants