Help:Import vocabulary (Best practices)

Jump to: navigation, search

As explained in Help:Import vocabulary, not every element of some external vocabulary can be imported. The easiest way for finding out whether something is available for import is to try importing it with a statement as the above. If this does not work, a message in the factbox will inform you about the problem. Possible reasons are:

  1. The namespace (e.g. "foaf:") is not available at all. The wiki does not know what it refers to, and it does not support any elements from this range.
  2. The specific element (e.g. "foaf:knows") is not available in the (known) namespace "foaf:".
  3. The element is known, but it cannot be imported for the specific kind of page you are trying to use it on. For example, you cannot import foaf:knows on a page in the wiki-namespace "Category:" since it should always be a "Property:".

In the last case, you can fix the problem by using an appropriate article for import. In the other cases, only users with administrator privileges can add the unknown vocabulary elements. This can be done very quickly by modifying the wiki (see here), but there are also cases in which some vocabulary is not made available on purpose. Possible reasons for this are:

Best practices

  • The element you wish to use is not recommended for public use yet, or its correct use is still discussed in the community. An example of this is foaf:OnlineEcommerceAccount.
  • The specification of the chosen vocabulary is too ambiguous or preliminary for current use. It might become more precise later which would affect the usage in the wiki (or render its earlier usage incorrect).
  • The vocabulary is not widespread and standard, and the community of the wiki (represented by its admins) does not endorse its use at the moment. Not everyone's home-made ontology needs to be imported in a wiki.
  • The specification of the vocabulary is tailored towards another ontology language than that of the wiki (OWL DL), and it is not clear how to map it correctly. Since importing some vocabulary also entails a mapping to OWL DL it must be specified how the mapping should be done. It is also questionable whether exporting such elements to OWL/RDF would be of much use.
  • The imported element is part of the ontology vocabularies used for export.
    • In this case, using the element also directly could impair the sanity of the export. E.g. if owl:Nothing would be imported as a category into the wiki, one could easily make the whole output inconsistent by adding some article to this class, which is not desirable.
    • Alternatively, the element could already be sufficiently represented implicitly in the wiki. E.g. in order to state that something is an element of a class, one does not need to import the property rdf:type — it suffices to use the available category mechanism.

A quick way to find out what elements are available for some namespace abbreviation is to go to the article MediaWiki:smw_import_foaf, with foaf replaced by the namespace identifier you are interested in. The rationale behind this system is that the community can decide on a sane use of desired vocabularies, but each user still has the power to decide in which cases the available elements are used and by what name they should be represented within the wiki.

Changing import statements

It can easily happen that some existing article of the wiki should be modified to represent (another) imported concept. For example, a wiki community that already uses a category "Person" might decide to map this category to "foaf:Person" in the future. Luckily, this is not a problem. Import statements in existing articles can be changed at any point in time without requiring additional updates in the wiki.

The exported RDF will immediately be modified accordingly. Of course, in the case of properties, the datatype should usually not be changed without updating also the articles that use this property. This is mildly related to importing since an "imported from" declaration for properties will also define the datatype.