Re: Re 2: More specific proposal on the vocabulary expansion (a.k.a. vocab proxy) feature

On Aug 5, 2011, at 1:52 AM, "Ivan Herman" <ivan@w3.org> wrote:

> Forgetting the admin issues:-)
> 
> On Aug 4, 2011, at 20:10 , Gregg Kellogg wrote:
>> 
>> We had also discussed that datatype coercion would be something that a proxy vocabulary might accomplish, however, as I mentioned, I don't think this can be done through normal entailment regimes. It's also a theme in recent Microdata-RDF discussions [5] which have a similar issue. @itemvaltype is not universally loved, and it's questionable how much @datatype is used properly in RDFa. Clearly, being able to use some combination of rdfs:range and lexical value space could be useful in reproducing this, but it would seem to need to be done at processing time, not after the fact.
>> 
>> If we could solve this issue, it would be useful across all RDF serializations where publishers are often lazy about using typed literals.
> 
> 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.

> 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.

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

Received on Friday, 5 August 2011 14:56:17 UTC