Last modified: 2007-10-03 16:54:28 UTC
A property without a type (it has no Property: page or its Property: page does not specify a has_type special property) exports in RDF as owl:ObjectProperty. But a property that says it has_type Type:Page exports as owl:DatatypeProperty, same as if it was of type integer, string, etc. This might be a bug in SMWTypesValue getTypeID() , it's not returning _wpg for a property of Type:Page. getXSDValue() does return _wpg but maybe that should return the localized "Page"?
The export behaviour is indeed a bug -- Denny should have a look at it. The other stuff is as intended. Things now work as follows: SMWDataValue is the base class for representing all of SMW's data values. For various datatypes, there are special subclasses that implement a suitable data container (but one such class may be used for multiple datatypes if processing is very similar). Given such a container, the method getTypeID() is the only way of finding out what type of value it contains (since the PHP class is not precise about this). In order to make it easier for code to use this type information, getTypeID does no longer use any localised names but has an internal ID for all known types. User-defined types use their page title as ID, while the internal IDs always start with "_" to avoid confusion (titles cannot start with spaces). So, SMWTypeValue is a container for a special type of data, namely type information. It's proper ID is '__typ' (the two '_' signifying that it is an internal type that users cannot use for their properties). The SMWTypeValue-container implements all processing of has_type and formats the output (using links to "Type:" pages, even if no namespace was given). When retrieving the type of a property from the database, you always get such an SMWDataValue, and you are not intereseted in its ID but in its content. Its content (like for every SMWDataValue) comes in two different forms: an "XSD-Value" that is used internally for storing data, and a "Wiki-Value" that is similar to what users would enter in the wiki. The XSD-Value is basically the Type-ID that values of a property of that type would show (the exception is that nary values, the XSD-Value encodes the structure of the nary, while the type id of the according SMWNAryValue is just '__nry'). If you want a localised name, you need to access getWikiValue(). If you want a formatted text for displaying the type information, you should use getShortWikiText, getShortHTMLText, getLongWikiTExt, or getLongHTMLText as appropriate. Note that quite some datavalues still use the old type system (SMWOldDataValue is the wrapper there), and they might not behave as they should when asking for their type ID. This will change. This is also why Special:Types does no longer display the unit information: the united types still use the old system and so the API for finding the units will change anyway. I will extend Special:Types with further information after the refactoring for all types is finished. SMWDataValues also control their RDF export, and can do whatever they like there. In order to encode built-in types in RDF, we might need to use special URIs (since these types are universal and not special to a given wiki). The local URI of the type in the wiki might not be the best solution. We are thinking about publishing a suitable ontology/vocabulary for SMW in the near future.
I fixed this for now, but together with the more customised RDF export of SMW1.0, the selection of Obejct- vs. DatatypeProperty should also be made more flexible, instead of being hardcoded in the export.
