W3C home > Mailing lists > Public > public-rdf-wg@w3.org > June 2011

Re: long-range datatyping and rdfa/microdata

From: Pat Hayes <phayes@ihmc.us>
Date: Thu, 9 Jun 2011 20:32:20 -0500
Cc: RDF WG <public-rdf-wg@w3.org>
Message-Id: <6A6D0B39-3821-41C2-B096-0D82A6E5A824@ihmc.us>
To: Dan Brickley <danbri@danbri.org>

On Jun 8, 2011, at 11:02 AM, Dan Brickley wrote:

> Hi folks
> Firstly, apologies I couldn't make today's call. I've spent my RDF'ing
> time this week talking to a lot of people about schema.org,
> rdfa/microdata etc.
> I want to bring something up  related to that: back in RDFCore WG we
> called it "long range" data-typing, but didn't figure out a way to
> make it work.

I often tell people who say disparaging or condescending things about standardization that it took the RDFCore WG longer to decide how to write the number three than it takes to make a baby. One of the main reasons for this was trying something like a dozen different ways to try to make this 'long-range' datatyping work, none of which turned out to be viable for one reason or another. 

> I'd appreciate if someone could articulate the
> connection to current discussion on literals

I dont think it has any particular connection with the current discussion.

> , and suggest if there are
> ways we could make it work in 2011.

I don't see why it should be any easier now than it was back then. 

> The idea is that many properties are deployed as if their values take
> string form, but we know from the schema that the values can be
> interpreted e.g. as integers or dates.
> RDF's datatyping mechanism puts a lot of burden on instance data, and
> in some contexts (eg. Website markup) this can be problematic. So for
> example http://schema.org/docs/datamodel.html chooses Microdata over
> RDFa and lists 'datatypes' as one of the complexity burdens of RDFa
> markup.
> In practice I don't think a lot of sites will enjoy marking up each
> property value occurence with a datatype, ... and so vocabulary
> designers are tending not to make datatyping explicit.
> So for example in FOAF we have foaf:age, which Peter Mika originally asked for.
> http://xmlns.com/foaf/0.1/#term_age "The age property is a
> relationship between a Agent and an integer string representing their
> age in years. "
> This can be used in RDFa as so: <p>blah blah <span
> property="foaf:age">39</span> blah</p>.
> If we try to persuade publishers to put datatype="xsd:integer"
> alongside each age, ... we'll have a hard time. So is there anything
> we can do at the schema level?  Mumble mumble range mumble...

Why not just define foaf:age so that its value is a string representing an integer, rather than an actual number? That is what the documentation cited above actually says :-)
> Pat - can you remember why we couldn't make this work in the semantics
> last time?

The chief problem, as I recollect, was nonmonotonicity. If you just have a plain literal as a property value, it denotes a string. But if you add a triple assigning a datatype to the property range, that plain literal isn't plain any more, and it denotes something different. That breaks the underlying RDF semantic model. 

There are ways we can try to wiggle around this. We could for example say that 

:a :p "string" .
:p rdfs:range :Type .


:a :p "string"^^:Type .

ie this is true **in addition** to the first triple, rather than replacing or re-interpreting it. I suspect this might not fly, however. 

I think I may have some old notes buried somewhere on the various ideas that were tried. If the WG thinks this can is worth re-opening, I could try to dig them out. 


> cheers,
> Dan
> (another possibility is to do something in RDFa's profile mechanism,
> http://www.w3.org/TR/rdfa-core/#s_profiles )

IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Friday, 10 June 2011 01:32:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:59 UTC