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, jmcclure@hypergrove.com 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
Wikidata-l@lists.wikimedia.org
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