New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract literal from @value of meter element #9

Closed
gkellogg opened this Issue Nov 2, 2014 · 7 comments

Comments

Projects
None yet
2 participants
@gkellogg
Member

gkellogg commented Nov 2, 2014

The meter element represents a scalar measurement within a known range, or a fractional value; for example disk usage, the relevance of a query result, or the fraction of a voting population to have selected a particular candidate.

Depending on the lexical form of the value of the @value attribute:

  1. if the value has the lexical form of an xsd:integer, value is a literal with datatype xsd:integer
  2. if the value has the lexical form of an xsd:float, value is a literal with datatype xsd:float
  3. if the value has the lexical form of an xsd:double, value is a literal with datatype xsd:double
  4. Otherwise, value is a Plain Literal without language or datatype.

The follow markup:

<meter itemprop="integer" value="1">1cm</meter>
<meter itemprop="float" value="1.1">1.1cm</meter>
<meter itemprop="double" value="1.1e1">1.1<sup>1</sup></meter>
<meter itemprop="plain" value="foo">foo</meter>

would generate the following:

[
  <http://example/integer > "1"^^xsd:integer;
  <http://example/float> "1.1"^^xsd:float;
  <http://example/double> "1.1e1"^^xsd:double;
  <http://example/plain> "foo";
] .

gkellogg added a commit that referenced this issue Nov 2, 2014

Add marker for issue #9 and property value information on how to cons…
…truct a literal from the `@value` of the `meter` element.
@iherman

This comment has been minimized.

Show comment
Hide comment
@iherman

iherman Nov 3, 2014

Member

The only caveat is that differentiating between double and float is not that simple if the underlying infrastructure does not have explicit conversions for it. Eg, python, out of the box, does not make any difference (in fact, everything is a double). So maybe we can require to generate double everywhere to avoid this problem...

Ivan

On 02 Nov 2014, at 21:57 , Gregg Kellogg notifications@github.com wrote:

The HTMLmeter element is used specifically to provide metadata using the value of the @value attribute [1]. As this attribute is intended to be machine-readable, a datatyped value may result.

Depending on the lexical form of the value of the @value attribute:

• if the value has the lexical form of an xsd:integer, value is a literal with datatype xsd:integer
• if the value has the lexical form of an xsd:float, value is a literal with datatype xsd:float
• if the value has the lexical form of an xsd:double, value is a literal with datatype xsd:double
• Otherwise, value is a Plain Literal without language or datatype.
The follow markup:

1cm
1.1cm
1.11
foo

would generate the following:

[
<http://example/integer > "1"^^xsd:integer;
http://example/float "1.1"^^xsd:float;
http://example/double "1.1e1"^^xsd:double;
http://example/plain "foo";
] .


Reply to this email directly or view it on GitHub.


Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
GPG: 0x343F1A3D
WebID: http://www.ivan-herman.net/foaf#me

Member

iherman commented Nov 3, 2014

The only caveat is that differentiating between double and float is not that simple if the underlying infrastructure does not have explicit conversions for it. Eg, python, out of the box, does not make any difference (in fact, everything is a double). So maybe we can require to generate double everywhere to avoid this problem...

Ivan

On 02 Nov 2014, at 21:57 , Gregg Kellogg notifications@github.com wrote:

The HTMLmeter element is used specifically to provide metadata using the value of the @value attribute [1]. As this attribute is intended to be machine-readable, a datatyped value may result.

Depending on the lexical form of the value of the @value attribute:

• if the value has the lexical form of an xsd:integer, value is a literal with datatype xsd:integer
• if the value has the lexical form of an xsd:float, value is a literal with datatype xsd:float
• if the value has the lexical form of an xsd:double, value is a literal with datatype xsd:double
• Otherwise, value is a Plain Literal without language or datatype.
The follow markup:

1cm
1.1cm
1.11
foo

would generate the following:

[
<http://example/integer > "1"^^xsd:integer;
http://example/float "1.1"^^xsd:float;
http://example/double "1.1e1"^^xsd:double;
http://example/plain "foo";
] .


Reply to this email directly or view it on GitHub.


Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
GPG: 0x343F1A3D
WebID: http://www.ivan-herman.net/foaf#me

@gkellogg

This comment has been minimized.

Show comment
Hide comment
@gkellogg

gkellogg Nov 3, 2014

Member

So, using the DOM, you don't have access to the lexical form in Python? Otherwise, I don't see the problem.

That said, I could live without supporting xsd:double.

Member

gkellogg commented Nov 3, 2014

So, using the DOM, you don't have access to the lexical form in Python? Otherwise, I don't see the problem.

That said, I could live without supporting xsd:double.

@iherman

This comment has been minimized.

Show comment
Hide comment
@iherman

iherman Nov 3, 2014

Member

On 03 Nov 2014, at 16:14 , Gregg Kellogg notifications@github.com wrote:

So, using the DOM, you don't have access to the lexical form in Python? Otherwise, I don't see the problem.

Well... That means the implementation has to get into the parsing of the lexical form, instead of simply using the core library of the underlying environment. Ie

try :
a = float("lexicalform")
except :
# it is not a float/double, do something

I have to get and parse "lexicalform". Of course doable, but I am lazy:-) and I do not see the huge benefit...

Ivan

That said, I could live without supporting xsd:double.


Reply to this email directly or view it on GitHub.


Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

Member

iherman commented Nov 3, 2014

On 03 Nov 2014, at 16:14 , Gregg Kellogg notifications@github.com wrote:

So, using the DOM, you don't have access to the lexical form in Python? Otherwise, I don't see the problem.

Well... That means the implementation has to get into the parsing of the lexical form, instead of simply using the core library of the underlying environment. Ie

try :
a = float("lexicalform")
except :
# it is not a float/double, do something

I have to get and parse "lexicalform". Of course doable, but I am lazy:-) and I do not see the huge benefit...

Ivan

That said, I could live without supporting xsd:double.


Reply to this email directly or view it on GitHub.


Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

@iherman

This comment has been minimized.

Show comment
Hide comment
@iherman

iherman Nov 11, 2014

Member

The implementation, in languages that do not make a difference between float and double (e.g., Python) means that the value must be checked, e.g., whether it is larger than 3.40282366920938E38 to decide whether it is xsd:double or xsd:float. This can of course be done.

I am not sure it makes a huge difference in practice in the sense of whether it makes sense to differentiate between double and float. My instinct would say to use double and integer, and that is all, but I am happy to go with the flow. Apart from this detail, I am happy to move on with this as described.

Member

iherman commented Nov 11, 2014

The implementation, in languages that do not make a difference between float and double (e.g., Python) means that the value must be checked, e.g., whether it is larger than 3.40282366920938E38 to decide whether it is xsd:double or xsd:float. This can of course be done.

I am not sure it makes a huge difference in practice in the sense of whether it makes sense to differentiate between double and float. My instinct would say to use double and integer, and that is all, but I am happy to go with the flow. Apart from this detail, I am happy to move on with this as described.

@gkellogg

This comment has been minimized.

Show comment
Hide comment
@gkellogg

gkellogg Nov 11, 2014

Member

The language in the spec supports just integer and float, is that sufficient? I a free that for most Microdata use, double isn't important.

Member

gkellogg commented Nov 11, 2014

The language in the spec supports just integer and float, is that sufficient? I a free that for most Microdata use, double isn't important.

@gkellogg

This comment has been minimized.

Show comment
Hide comment
@gkellogg

gkellogg Nov 11, 2014

Member

Alternatively, I'd be fine with saying that if the form is float or double, use double.

Member

gkellogg commented Nov 11, 2014

Alternatively, I'd be fine with saying that if the form is float or double, use double.

@iherman

This comment has been minimized.

Show comment
Hide comment
@iherman

iherman Nov 11, 2014

Member

On 11 Nov 2014, at 16:42 , Gregg Kellogg notifications@github.com wrote:

Alternatively, I'd be fine with saying that if the form is float or double, use double.

That would certainly facilitate things. I do not think the world would collapse if we used only double.

Ivan


Reply to this email directly or view it on GitHub.


Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

Member

iherman commented Nov 11, 2014

On 11 Nov 2014, at 16:42 , Gregg Kellogg notifications@github.com wrote:

Alternatively, I'd be fine with saying that if the form is float or double, use double.

That would certainly facilitate things. I do not think the world would collapse if we used only double.

Ivan


Reply to this email directly or view it on GitHub.


Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment