RE: Formation of RDF terms

Since this past Novemeber I have had to ignore this mailing list so
please pardon if this point has recently been beaten, but I have been
implementing and filling a database with just such shorthand RDF
tuples (over 750,000 of them), and found it works quite well and is
even practical.

Consider a few typical Statements { s,p,o }.

{ Station:hilltop, gps:northing, 7654321 }
{ Station:hilltop, gps:easting, 1234567 }
{ Station:hilltop, rdf:type, rdf:Seq }
{ Station:hilltop, rdf:_1, measurement:w0001 }

{ measurement:w0001, method:ANEMHW, param:WINDSPEED }
{ measurement:w0001, uom:M_S, 1.2 }

{ uom:M_S, has:definition, meters per second }
{ meathod:ANEMHW, has:definition, A Hot-wire anemometer
  is used to measure air flow. }
...

(Note I could not use rdfs:isDefinedBy since the objects are literals
and I did not need to go through the trouble for this
(single-language) project to formally identify each definition.)

Once all the namespaces (naming authorities) are defined locally for
the database, these statements are reasonably clear both to humans,
and to machines.   They are also short enough to be searched and
sorted efficiently, yet can easily be packaged fully qualified or
unambiguously as XML for transport to other systems.

In all, I have found the shorthand QName syntax very useful and
valuable in practice, even for primarily numerical data many may have
considered unsuitable for RDF.  (It's not difficult to process
numbers, but it can be impossible to find and process the _right_
numbers if they do not reside in a simple framework people can
understand.)

> Aaron Swartz wrote:
>
> Whatever the rule is for predicates ought be the same for
> subjects (e.g.
> typedNode).
>
> (see http://www.openhealth.org/RDF/QNameToURI.htm )
>
> While we are at it, such a rule could allow a 'shorthand' use
> of qname as a
> rdf:resource value:
>
> e.g.
>
> <foo:bar id="http://yada.com">
>     <foo:baz rdf:resource="foo:bop" />
> </foo:bar>
>
>
> -Jonathan
>
>

Received on Friday, 26 January 2001 17:28:10 UTC