WARNING: this is still a draft, and some details are still in discussion.

Vocabulary Search on the Semantic Web for RDFa Default Profiles

The table below contains the top 100 of the complete search and processing for Default Profile Vocabularies as performed by Sindice. See the the separate section below that explains the methodology leading to this table.

The content of each columns are:

1. (Partial) URI of the vocabulary
2. Number of Triples that use the vocabulary
3. Number of Graphs that use the vocabulary
4. Number of domains that use the vocabulary
5. Number of 2^nd level domains that use the vocabulary (i.e., http://a.b.c and http://q.b.c are considered as identical)

The domains’ data is important for the purpose of a default profile: if a vocabulary is used by a large number of triples but all originating at one or few domains only, that indicates that the vocabulary is used only in a few, albeit possibly very large datasets. Although these datasets may be very important resources, nevertheless, this would not warrant adding the vocabulary to be part of a generic default profile. To be precise about the content of the table, it contains the top 100 entries through a dicreasing order of the 2^nd level domain value. The full search results is also available in CSV format (beware, the data set is over 140M, containing more than 1,800,000 entries).

By default, the table is sorted using its last column, in decreasing order. Clicking on the column header reorders the table using that column, first in increasing and, clicking again, by decreasing order.

How Was the Data Collected?

The fundamental approach is to search the Semantic Web for vocabulary usage and process the results in order to derive possible vocabularies that are suitable for an RDFa Default Profile. The detailed steps are as follows.

1. A crawl of the Sindice search engine produced a list of properties and classes, based on a sample of around 10B triples retrieved on the Semantic Web.
2. The result of the crawl was subject to a number of processing steps, namely:
   1. Using some simple heuristics (and, in many cases, manual rules to overcome errors in the dataset) the property and class URI-s were used to establish the vocabulary URI-s. (Although, in cases where the number of domains using a specific vocabulary was very low, i.e., 1 or 2, the manual rule set did not have the corresponding rule because the end result would not be used for a default vocabulary anyway.)
   2. A number of vocabularies were eliminated as unsuitable for an RDFa profile.
   3. Some common mistakes in the datasets had to be handled, too. For example, a missing '#' or a '/' at the end of a property yields, formally, a different property URI but, in many cases, it was fairly clear that those were mistakes and could be merged with the intended URI. Another, somewhat more controversial, case is when a known vocabulary has changed its official URI at some point (e.g., Facebook’s Open Graph Protocol), and all data are merged into the current, official URI.
3. The resulting set of vocabularies were categorized along different axes: number of triples they appeared in, number of graphs they appeared in, and the number of different domains they appeared (both top level and second level domains).

The most complex and possibly controversial step is 2.2 above. Here are the categories of vocabularies that were removed from the result set:

• Vocabularies defined through a W3C Recommendation or Working/Interest Group Note (indeed, those are part of a default profile “ex officio”)
• Vocabularies whose URI is not referencable publicly, or that does not refer to a proper documentation (at the minimum a commented RDF file)
• Vocabularies marked as “draft”, “experimental”, etc., were removed
• Vocabularies used for a very specific and specialized purpose (e.g., major ontologies used in the medical or drug discovery areas).