This seems like a reasonable compromise to me. Other option would be a checkbox "use labels/metadata from imported file to label ontology"
I would also suggest that a service endpoint to import a RDF file is exposed directly - then people can write scripts to load all files in a directory for example. On Wed, 16 Jan 2019 at 18:46, Holger Knublauch <[email protected]> wrote: > Hi Rob, > > just to double-check on this ticket. I have just implemented a change for > 6.2 so that the rdfs:label will only be replaced if it is "similar" to the > graphID. Example: > > 1) User creates an Ontology and enters a label "Kennedys" > 2) The system turns this into a graph/asset collection with ID "kennedys", > urn:x-evn-master:kennedys > 3a) Into this empty Ontology, import a file that has an owl:Ontology with > rdfs:label "Kennedys Ontology" > In this case, the label will become "Kennedys Ontology", because the > graph ID can be derived from the current label "Kennedys" > > 3b) Subsequently import a file that has an owl:Ontology with rdfs:label > "Other Ontology". > In this case, the label will be kept, because it is regarded as having > been edited. > > I just want to double-check that this process addresses the original > concern that you had (in case you remember). It does suggest an order in > which such imports typically happen (if you accumulate multiple files) and > also supports the scenario where someone just puts in an initial short name > so that the system also produces a short graph ID, while the full label is > expected from the RDF file. > > Holger > > > On 14/11/2018 1:17 pm, Rob Atkinson wrote: > > :-) > > > On Wed, 14 Nov 2018 at 13:03, Holger Knublauch <[email protected]> > wrote: > >> I agree that replacing the old label only if it differs from a default >> (based on the graph ID) is a good policy. Recorded for 6.2. >> >> Meanwhile please pre-process the files in TBC before importing. >> >> Holger >> >> >> >> On 14/11/2018 11:32 AM, Rob Atkinson wrote: >> >> >> Yes - the Use Case is an aggregation, but I want to use TBC to edit >> these, so i need the import of the model, and an ontology object. >> >> feels like this behaviour should be optional if you really have a good >> use case to replace it repeatedly - otherwise maybe detect if its the >> default name and replace only first time. >> >> On Wed, 14 Nov 2018 at 12:13, Holger Knublauch <[email protected]> >> wrote: >> >>> Hi Rob, >>> >>> apologies for the geeky reply. The relevant code is >>> >>> >>> // TBS-94: Copy other useful triples into main owl:Ontology >>> for(Resource ont : model.listSubjectsWithProperty(RDF.type, >>> OWL.Ontology).toList()) { >>> for(Statement s : ont.listProperties().toList()) { >>> if(!s.getObject().isAnon() && >>> !SWA.defaultNamespace.equals(s.getPredicate()) && >>> !RDF.type.equals(s.getPredicate())) { >>> model.add(ontology, s.getPredicate(), >>> s.getObject()); >>> if(RDFS.label.equals(s.getPredicate())) { >>> // Replace rdfs:labels so that the teamwork >>> graph doesn't have two labels >>> >>> deleteModel.add(ontology.listProperties(RDFS.label)); >>> } >>> } >>> } >>> } >>> So it copies most triples, but replaces the rdfs:label. This policy is >>> of course debatable, and I believe it has been discussed before. On one >>> hand the label should be replaced in cases where the user has simply >>> created a new empty graph and then imports an existing RDF file from a >>> previous export. In that case the original label didn't mean much. But OTOH >>> there can be cases where this policy is not desirable. What kind of file >>> are you importing that shouldn't cause this behavior? Is this some kind of >>> accumulation of TTL files into one? >>> >>> Holger >>> >>> >>> On 14/11/2018 9:48 AM, Rob Atkinson wrote: >>> >>> If the imported RDF file declares an object as an Ontology with a label >>> then the importing it into an Asset Collection interferes with the >>> existing label. >>> >>> What other metadata is affected (owl:imports) - and what should be the >>> contract here - IMHO Ontology objects should be ignored on import if they >>> are referenced inside EDG - or at least the behaviour needs to be >>> explicitly explained on the default import page. >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "TopBraid Suite Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "TopBraid Suite Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "TopBraid Suite Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "TopBraid Suite Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
