Re: revisiting 'position', 'episodeNumber', 'seasonNumber' modeling and Periodicals

Someone has to absorb the costs of interpreting the data.  This should
always fall on the client side.  This always means me, and I am used to it,
and gladly pay the costs.
Schema.org already does quite a bit to help with interpretation, but only
so much as Martin aptly puts with regard to "web-scale" in some cases, but
that is OK for now.

The costs of interpreting data should try to be kept to a minimum.  This
happens now and if all of us continue to do our homework and make
Schema.org a viable publishing standard for structured data as much as
possible.

I live and breathe (and work) as a Data Architect, and I am one of those
stakeholders absorbing much of all that we put together.  So far, it has
been rather trivial for my own tool sets to handle.

Please, do not put any more burden on the Publishers...they do pretty darn
great so far, and I want them to publish faster and more...and I will
happily pay the costs and develop my own client processing rules, when and
where I need to. (and I am one of the small stakeholders...size: 1 - me) :-)

The real problem and hard part is getting Publishers to always use a
property like http://schema.org/episodeNumber !  (having 'Number' as a term
within the property might cause some confusion) Make it easy for them to
always use the property by explaining well how it can be used, good
definitions, good examples, etc (whatever it may be called), and you make
my job / life easier as a consumer of all their data.

My personal preference for all of these kind of datatype issues where
"Numeric values that might NOT ALWAYS GET PUBLISHED as numeric values" has
always been "string", since I (and the Publishers) will be hanging off of a
really cool "Thing property" we never had before, then the interpretation
is very trivial typically for me.

-- 
-Thad
+ThadGuidry <https://www.google.com/+ThadGuidry>
Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>