Using the dotted notation, XSD datatype facets such as below can be specified easily as properties using a simple colon:
Property: .anyType:equal - (sameAs equivaluent) redirect to page/object with actual numeric value Property: .anyType:ordered - a boolean property Property: .anyType:bounded - a boolean property Property: .anyType:cardinality - a boolean property Property: .anyType:numeric - a boolean property Property: .anyType:length - number of chars allowed for value Property: .anyType:minLength - min nbr of chars for value Property: .anyType:maxLength - max nbr of chars for value Property: .anyType:pattern - regex string Property: .anyType:enumeration - specified values comprising value space Property: .anyType:whiteSpace - reserve or replace or collapse Property: .anyType:maxExclusive - number for an upper bound Property: .anyType:maxInclusive - number for an upper bound Property: .anyType:minExclusive - number for an lower bound Property: .anyType:minInclusive - number for an lower bound Property: .anyType:totalDigits - number of total digits Property: .anyType:fractionDigits - number of digits in the fractional part of a number An anonymous object is used to represent namespace-qualified (text & url) values eg_ rdf:about_: Property: .:rdf:about - this is a .url value for an RDF "about" property for a page/object Property: .:skos:prefLabel - this is a .name value for a page/object I suggest that properties for "precision" can be found in XSD facets above. - john On 19.12.2012 12:41, [email protected] wrote: > Here's a suggestion. Property names for numeric information seem to be on the table -- these should be viewed systematically not haphazardly. > > If all text properties had a "dotted" lower-case name, life would be simpler in SMW land all around and maybe Wikidata land too. All page names have an initial capital as a consequence of requiring all text properties to be named with an initial "period" followed by a lower-case letter. The SMW tool mandates the properties from which all derive: .text, .string and .number are basic (along with others like .page). Then, strings have language-based subproperties and number expression subproperties, and numbers have XSD datatype subpropertiess, which in turn have SI unit type subproperties, and so on. > > Here's a "Consolidated Listing of ISO 639, ISO 4217, SI Measurement Symbols, and World Time Zones [2]" [1] to illustrate that it is possible to create a unified string- & numeric-type property name dictionary across a wide swath of the standards world. The document lists a few overlapping symbols then re-assigned to another symbol. > > Adopting a "dotted name" text-property naming convention, can segue to easier user interfaces too for query forms at least plus impacts exploited by an SMW query engine. What is meant by these expressions seems pretty natural to most people: > > Property: Height - the value is a wiki pagename or objectname for a "height" numeric object > Property: .text - (on Height) the value is text markup associated with the Height object > Property: .string - (on Height) the value is text non-markup data for the Height object > Property: .ft - (on Height) the value is number of feet associated with the Height object > Property: Height.text - the value is text markup associated with an anonymous Height object > Property: Height.string - the value is a "string" property of an anonymous Height object > Property: Height.ft - the value is a "feet" property of an anonymous Height object > > [1] http://www.hypergrove.com/Publications/Symbols.html > > _______________________________________________ > Wikidata-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikidata-l [1] Links: ------ [1] https://lists.wikimedia.org/mailman/listinfo/wikidata-l [2] http://www.hypergrove.com/Publications/Symbols.html
_______________________________________________ Wikidata-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-l
