Someone sent me the following. They had been following each "See Also" link on http://open-services.net/wiki/reconciliation/Common-IT-Resource-Type-Vocabulary-Version-2.0/
> can't find data type for the following properties from crtv: > assetTag, dependsOn, elementFrom, elementTo, observationTime, occursBefore, processId, version I looked into this far enough to conclude that there are several classes of problem behind this: 1: Terms whose see-also links whose document URL works, but whose fragment component (id) is not found at the target URL. Example: assetTag 2: Terms without any see-also links. Aside from the window between start of drafting and entry into convergence, it's hard to think of why >0 of these should exist. Given that Recon is not *in* that window, they're bugs. There should be >=1 exploiting spec for each term, and it should be pointed to. Examples: most aside from assetTag 3: To cover the drafting window, and perhaps to cover other cases where other parties ask Recon to define terms required by their scenarios that "seem common", we could use the "vocabulary term maturity annotation vocabulary" that Core has recently been discussing. That's probably more optional. Today value-types are asserted in specifications, not vocabulary. There might be a case to be made for asserting a "default" value type at the vocabulary level to satisfy requests like this, but unless we feel the need to experiment we're better off waiting for Core to establish practices there. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
