# InterpretationProperties

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

An intuitively obvious way to model quantities is:

```:building :height [ :magnitude "20"; :units :meter].
```

But this is a train wreck waiting to happen, because we'd like

```[ :magnitude "20"; :units :meter] = [ :magnitude "2000"; :units :centimeter].
:building :height [ :magnitude "2000"; :units :centimeter].

```

but then we get

```:building :height [ :magnitude "20", "2000"; :units :meter, :centimeter]
```

which is all messed up.

Therefore,

Use InterpretationProperties to relate quantities to magnitudes:

```:building :height [ :meters "20"; :centimeters "2000" ].
```

But

For RdfCalendar, it's not clear whether 10am Chicago time is really the same as 11am New York time. For iCalendar round-tripping, it's probably not sufficient to convert everything to Z time, especially when you consider recurring events. Though the times are equivalent around the planet, i.e. { 10AM-CST t:sameTimeAs 11AM-EST }, they're not equivalent in their lexical representations, { 10AM-CST t:differentRepresentationTo 11AM-EST }, so it depends which distinction is important to you: if your calendar agent's capabilities include "preserve representations" then you'll have to avoid merging times linked with t:differentRepresentationTo; if the capabilities include "merge times" as a higher preference, on the other hand, you can go ahead and merge them.

Alternative:

Another approach is to add an additional level of indirection on a resource-level, the error in the strawman without interpretation property above is that the range of :height is physical:Height but the domain of :units and of :magnitude is not physical:Height but rather something like :heightOperationalizationRepresentation, so a straight-forward fix would be:

```:building :height [ a physical:Length; :opRep [a :heightOperationalizationRepresentation; :magnitude "20"; :units :meter]].
```

Now the following is true:

```[ a physical:Length; :opRep [a :heightOperationalizationRepresentation; :magnitude "20"; :units :meter]] = [ a physical:Length; :opRep [a :heightOperationalizationRepresentation; :magnitude "2000"; :units :centimeter]].
:building :height [ a physical:Length; :opRep [a :heightOperationalizationRepresentation; :magnitude "2000"; :units :centimeter]].
```

including what we get:

```:building :height [ a physical:Length; :opRep [a :heightOperationalizationRepresentation; :magnitude "20"; :units :meter]; :opRep [a :heightOperationalizationRepresentation; :magnitude "2000"; :units :centimeter]].
```

magnitude and :units would be combined-ifps for the :heightOperationalizationRepresentation, and the following is false:

```[a :heightOperationalizationRepresentation; :magnitude "20"; :units :meter]= [a :heightOperationalizationRepresentation; :magnitude "2000"; :units :centimeter].  #WRONG!
```

This approach genrated more triples but in some situations it may be unpractical to use InterpretationProperties, for example in an application designed to allow the user to add new units, but not to define new properties.

hmm... multiple reference systems notes...

This page uses a ShorthandRDF syntax. See #swig 2006-04-05 for an example discussion of InterpretationProperties. One issue raised in this discussion was what advantage { :building :height [ :meters "20"; :centimeters "2000" ] } has over { :building :meters "20"; :centimeters "2000" }, which becomes even clearer when you think about :md5 and :sha1.

credits: taken from discussion 26 Mar 2003, design note on Interpretation Properties, TimBL, 1998-2001