- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 5 Aug 2011 17:08:20 +0200
- To: Gregg Kellogg <gregg@kellogg-assoc.com>
- Cc: W3C RDFWA WG <public-rdfa-wg@w3.org>
On Aug 5, 2011, at 16:55 , Gregg Kellogg wrote: [snip] > On Aug 5, 2011, at 1:52 AM, "Ivan Herman" <ivan@w3.org> wrote: >> So... I have given some more thoughts and I have to retract what I said yesterday evening. Indeed, if we stick to RDFS or even OWL 2, this will not be solved. After all, what I think we are talking about is to make a literal->literal mapping that would add a datatype to a literal. No entailment that I know of does that. >> >> The issue I have is that, as you say, this has to be done during the core RDFa processing, not as a post-processing step. Otherwise you may end up by duplicating triples at the end, something like >> >> <a> <b> "1234", "1234"^^xsd:int. >> >> which is not really good. But the other danger is that there might be differences between RDFa processor outputs, depending on whether the processor implements this whole mechanism or not, and I think that would be even worse. >> >> I wonder whether it is not possible to something slightly different, ie, that *some* literals could be automatically interpreted with a datatype by the RDFa processor. I would expect only the very simple ones, like integers and floats. But we could say that, for example, >> >> <span property="bla">1234</span> >> >> would automatically generate >> >> <> <bla> "1234"^^xsd:integer . >> >> Note that, in Turtle, this could be written as >> >> <> <bla> 1234 . >> >> so there is an analogy there... >> >> In Turtle, decimal integers, floating point numbers (as xsd:double), and decimals (as xsd:decimal) are accepted this way. Maybe we could extend that with dates if they are in ISO formats (although dates are really really messy:-(. >> >> The question is what happens if the user does _not_ want that? Well, if there _is_ a datatype attribute set, than that takes priority. Ie, >> >> <span property="bla" datatype="xsd:string">1234</span> >> >> will generate >> >> <> <bla> "1234"^^xsd:string . >> >> (Note that with the latest resolutions of the W3C RDF WG, this could also be serialized with: >> >> <> <bla> "1234" . >> >> I believe that by introducing this we would cover most of the datatype use cases without mixing in the post processing. >> >> Thoughts? > > Given that we seem to be open to incompatible changes to the spec, I think this is the way to go. Basically, if the value is in the lexical space of an xsd datatype, it would create a typed literal that datatype, or could be made a Plain Literal through datatype="xsd:string" we may need to enumerate these datatypes and provide a match order, so that 123 is not interpreted as xsd:double. Actually... the issue of backward incompatibility is still open for discussion, I believe. Otherwise yes, I agree, but I think we should keep that to a minimum. The number of various xsd datatypes is large and we should keep this list to a minimum for the purpose of RDFa... > >> Ivan >> >> P.S. Yes, this is a little bit analogous to the issue on whether >> >> <span property="bla">http://www.w3.org</span> >> >> could be interpreted as >> >> <> <bla> <http://www.w3.org> . >> >> because it is some sort of an automatic interpretation of the literal. This has been discussed, maybe this is an issue we would reopen? Or is it a can of worm? > > This particular case could be problematic, since it could be interpreted as xsd:anyURI as well, as would "foo:bar". I'd rather see this sort of matching done for literals, not URIs. Yes, this *is* a can of worms, mainly with curie-s. But... I think the xsd:anyURI issue is a bit similar to the previous one. If I see <span property="bla" datatype="xsd:anyURI">http://www.w3.org</span> then I do _not_ create a URIRef object but keep it as a literal. This is probably the minority case, so authors would not mind doing that if they really want a literal... In general, for all the cases it should hold that the author's @datatype value wins over any automatism. Ivan > > That said, I think we could revisit what <a property="bla" href="http://www.w3.org">foo</a> results in. We could then deprecate @rel and @rev. This could also be more consistent with people's expectations for <img src="foo" property="depiction" />. I know this was considered and rejected before, but it might get a different response now. > >> ---- >> Ivan Herman, W3C Semantic Web Activity Lead >> Home: http://www.w3.org/People/Ivan/ >> mobile: +31-641044153 >> PGP Key: http://www.ivan-herman.net/pgpkey.html >> FOAF: http://www.ivan-herman.net/foaf.rdf > > Gregg ---- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Friday, 5 August 2011 15:06:32 UTC