When using the builtin "general" AssemblerGroup, do we need to create a custom FileManger assembler?

[aperera12]

Version

5.3.0

Question

I'm currently trying to create a group of nested models with the Assembler, and am using a document manager to manage multiple ontologies for an OntModel. I'm running into the issue where the assembler group is looking for an assembler for the DocumentManager ja:fileManager object, but that doesn't exist on the general assembler group.

Looking through the code, I want to think it would use the DocumentManagerAssembler's "getFileManager" method to assemble the FileManager, but it's looking for a root assembler on the group itself.

Assembly.ttl

@prefix ja: <http://jena.hpl.hp.com/2005/11/Assembler#> .
@prefix lm: <http://jena.hpl.hp.com/2004/08/location-mapping#> .
@prefix ja: <http://www.example.com/core/vocab/v2/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

<http://www.example.com/> a ja:UnionModel ;
    ja:subModel <http://www.example.com/test/> .

<http://www.example.com/test/> a ja:UnionModel ;
    ja:subModel <http://www.example.com/test/_model/vocab/> .

<http://www.example.com/test/_model/vocab/v1/> a ja:OntModel ;
    ja:ontModelSpec <http://www.example.com/test/_model/vocab/v1/spec/> .

<http://www.example.com/test/_model/vocab/v1/document-manager/> a ja:DocumentManager ;
    ja:fileManager [ ja:locationMapper <http://www.example.com/test/_model/vocab/v1/mapper/> ] .

<http://www.example.com/test/_model/vocab/v1/mapper/> lm:mapping [ lm:altName "file:/path/to/v1.vocab.ttl" ] ;
    lm:name "file:v1.vocab.ttl" .

<http://www.example.com/test/_model/vocab/v1/spec/> a ja:OntModelSpec ;
    ja:documentManager <http://www.example.com/test/_model/vocab/v1/document-manager/> .

<http://www.example.com/test/_model/vocab/v2/> a ja:OntModel ;
    ja:ontModelSpec <http://www.example.com/test/_model/vocab/v2/spec/> .

<http://www.example.com/test/_model/vocab/v2/document-manager/> a ja:DocumentManager ;
    ja:fileManager [ ja:locationMapper <http://www.example.com/test/_model/vocab/v2/mapper/> ] .

<http://www.example.com/test/_model/vocab/v2/mapper/> lm:mapping [ lm:altName "file:/path/to/v2.vocab.ttl" ] ;
    lm:name "file:v2.vocab.ttl" .

<http://www.example.com/test/_model/vocab/v2/spec/> a ja:OntModelSpec ;
    ja:documentManager <http://www.example.com/test/_model/vocab/v2/document-manager/> .

<http://www.example.com/test/_model/vocab/> a ja:UnionModel ;
    ja:subModel <http://www.example.com/test/_model/vocab/v1/>,
        <http://www.example.com/test/_model/vocab/v2/> .

DocumentManagerAssembler#getFileManager

[afs]

"root" may be misnamed. It is the node for the item to be assembled.

Could you turn this into a minimal tes case please?

@sszuev - jena-ontapi question - does it wire itself in the assemblers for the old API?

[sszuev]

"root" may be misnamed. It is the node for the item to be assembled.

Could you turn this into a minimal tes case please?

@sszuev - jena-ontapi question - does it wire itself in the assemblers for the old API?

Sorry, I missed the question.

"new" model doesn't work with Assembler and FileManger classes directly, it contains its own interface GraphRepository, which is open and can be extended. Having the specification, I can extend document management in the "new" model, now this management is very simple, but it seems to me sufficient in most cases.

[afs]

OK - I've created an issue #3322 for the general case of assemblers for jena-ontapi, with an eye to Jena 6.0.0 being able to take another step towards retiring jena-core/ontology.