- From: <bugzilla@jessica.w3.org>
- Date: Tue, 09 Aug 2011 00:08:14 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13465 Manu Sporny <msporny@digitalbazaar.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|NEEDSINFO | --- Comment #4 from Manu Sporny <msporny@digitalbazaar.com> 2011-08-09 00:08:12 UTC --- "If the property is given using a URL property element the type is implicitly a URL. Is that enough?" How does this happen? Is it machine readable? You are sort-of talking about type coercion here: http://json-ld.org/spec/ED/20110808#type-coercion Type coercion is just one aspect of this issue. Yes, adding type coercion to microdata would go toward addressing this issue. However, you can't always depend on type coercion - for example, when a vocabulary is used to specify multiple different types of units. For example - "weight" can be defined in a variety of different units of measurement. "If one doesn't understand the item's vocabulary itself, why would one be inspecting individual property values?" That's not the issue. The question should be "If a vocabulary term can express something like 'weight', what is the best way to associate the unit of measurement with the number?" "In what circumstances would a microdata consumer be able to make use of data type information, without any hardwired information about the vocabulary?" Not "microdata consumer" - "data consumer". You can have a software module that is capable of translating weights and measures into any unit that you want. You can include this software module in your software to do the translation accurately. For example - I have an application that works with recipes, one of the ways to declare an ingredient in a recipe is by weight. You have two major schools of thought on expressing weights - imperial and metric. There are hundreds of millions of people that use both, so asking people to use one or the other exclusively unnecessarily excludes hundreds of millions of people. So, you can't: * Tell people to just use metric measurements * Create a library that is capable of reading any type of short-hand for weights/measurements because of overlaps in short-hand for expressing weights/measures (m for minutes vs. metres, deg for degrees (angle) vs. degrees (temperature)). However, if you tag it with an IRI datatype, the datatype is unique and discoverable (you can provide other things like the name of the datatype in multiple different languages). A consuming application wouldn't have to know anything about the vocabulary to know that a datatype of http://example.org/measurement/temperature#fahrenheit is a measurement for temperature in degrees fahrenheit as well as how to express the value in a person's native language because dereferencing the IRI will provide a fair amount of other information about the measurement (like the language-native glyphs for the concept). "If it does have hardwired information about the vocabulary, why does data typing need to be part of the general syntax instead of the vocabulary-specific semantics?" You shouldn't hardwire this type of information in the vocabulary. See the use case above. "I looked at the use-cases that microdata was written to cover and didn't see any where it would be useful." Then add the recipe use case to Microdata. Being able to specify units of measurement is important when baking a cake, giving somebody a dose of medication, and when sending scientific instruments to Mars. "Why can't the vocabulary require that a particular type always be used, possibly a type that includes units in-band and therefore can accommodate different units without extra metadata (e.g. "5km", "5mi", "5m")?" I answer this above. Doing this is a hack that requires people to express their units of measurement in a specific way. People are not very good at doing this. "What's a concrete example where this would be useful, as opposed to hardwiring the units into the vocabulary?" See above. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Tuesday, 9 August 2011 00:08:19 UTC