Bruce, by default, Composer will search for "missing imports", when
the type definition for a resource (URL) is missing.  I.e. if you have
a triple such as {:myOnt <http://purl.org/dc/elements/1.1/creator>
"Bruce"}, Composer will note that there is no type definition for
<http://purl.org/dc/elements/1.1/creator>.  It will then search for a
model that will define the namespace - http://purl.org/dc/elements/1.1/
in this case.

Note also that the error message states that "The resources causing
this are listed in the error log".  And this is true.  You will see
one or more "Untyped resource" info entries in the error log.  Note
these are not errors, but information that the model may not be
complete. This is basic RDFS/OWL taken to a bit of an extreme where
all URLs are checked for their type definition.  The default check for
untyped resources can be turned off in Preferences > TopBraid Composer
> Input/Output, and uncheck 'Check for missing imports after
loading'.  It is common to do this, particularly when working with RDF
data.

It is also safe to cancel when Composer is searching for "missing
imports".  The result is basically the same as not getting the
"missing imports".  I.e. some triples will not have type statements,
but this is common and perfectly valid in RDF.

When you get the "Add missing imports" message, think carefully about
whether or not you want to add those imports.  There's a good chance
you don't.  I think you may have said 'Yes" one or more times, and
this added some owl:import statement that you may or may not want.
Some of these may be in the Web and will take some time to download
each time you open the file.  This is probably why you see a
degradation in load time.  One way to speed up loading is to place
some of these files into your workspace.  This eliminates download
latency.

You can see what files are being imported by going to the Ontology
Home and choosing the Form sub-tab.  This will show all of the
owl:imports for your file.  To see what model (class & property defs)
elements are being used, see the Statistics sub-tab.  This will
provide some indication of what files you need to import.

Of course you can always define a standard element yourself and avoid
the need for an import.  For example, if your file uses dc:creator,
and nothing else from the Dublin Core ontology, then create the triple
{<http://purl.org/dc/elements/1.1/creator> a rdf:Property}.  I.e. you
don't need to import the entire ontology to be using the standard -
the important part is that the URL matches the standard definition.
You can also define the 'dc' prefix (http://purl.org/dc/elements/
1.1/), which is generally a good idea.

In terms of finding out what is defined where,  Composer's UI gives
good information on that.  When a triple is imported from another
file, an arrow will appear in the icon in the form.  Mouse-over that
and a tooltip will appear with more information.  If you want to find
out all of the imports that are used in your model, I'd suggest using
some SPARQL queries.  The following will get the file defined for each
resource in the currently loaded file:

SELECT *
WHERE {
    ?s ?p ?o .
    BIND (smf:definedIn(?s) AS ?sfile)
    BIND (smf:definedIn(?p) AS ?pfile)
    BIND (smf:definedIn(?o) AS ?ofile)
}

Many variants of this can be used to filter for a specific import,
etc.

Load time is the only issue, correct?  I.e. once loaded the
performance issues do not continue (?)

-- Scott

On Jan 20, 11:37 pm, Bruce Whealton <[email protected]> wrote:
> Hello,
>          So, I created a RDF file to contain genealogical data.  I had
> been entering the data I had collected, using TBC.  At first, I
> actually started with a hand-coded RDF/XML file modeled after FOAF and
> then took out names that were not related... later I imported the
> Biographical vocabulary and the Relationships vocabulary.  It seems
> that every time I open it in TBC, even without making changes, it
> takes long and longer to open and it seems to have more and more
> namespaces.
>            The file does validate using the w3 RDF validator.  So,
> that is good.  However, how can I find things to remove from the file
> - imports I don't need.  At one point, I think I was seeing things
> related to a music ontology which had nothing to do with my data.  It
> might be in my foaf file, actually.
>           Can someone take a look at this 
> file:http://my-family-lineage.com/genealogy/BruceWhealtonJrGeno.rdf
> which was named with a shorter file name of 
> justhttp://my-family-lineage.com/genealogy/bio.rdf
> Maybe I need a file name that is somewhere between the long file name
> that I listed first and the bio.rdf file which isn't really
> descriptive enough.
>            I guess to appreciate what I am seeing, you'd have to open
> it in TBC.
>
> My foaf file can be found at:http://whealton.info/BruceWhealtonJr/foaf.rdf
> which was created in TBC and has the same problem with bloat in terms
> of the namespaces it has to get.
>          Isn't there a way for it to just get the imports once and
> save them and then not have to do a download each time?  Maybe that
> isn't possible with TBC.
>         I do seem to get more than the expected number of messages
> when opening the file each time.  I mean some of the messages don't
> make sense to me and I'm not sure whether or not to skip them or
> import them.
>           Also, in both the foaf and genealogy rdf files I have names
> that come from TBC.  I cannot delete these instances - I forget the
> error I get.
>        I hope you can trust that the files that I have listed don't
> have anything that you wouldn't to download...
> unless there is a better way to share files.
> Thanks,
> Bruce

-- 
You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en

Reply via email to