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(a)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(a)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