Re: Microdata to RDF: First Editor's Draft (ACTION-6)

I'm just adding it to the spec, as I don't believe it's controversial.

Gregg

On Oct 18, 2011, at 3:21 PM, Martin Hepp wrote:

> So someone should file an issue on this. It should be possible to specify the language of an invisible element.
> If not for the Microdata spec, then at least for the Microdata-to-RDF extraction, where language tags are a first-class citizen.
> Martin
> 
> On Oct 18, 2011, at 11:34 PM, Gregg Kellogg wrote:
> 
>> Language tagged literals are supported, but for some reason not on meta. See "property values" in my spec.
>> 
>> Gregg Kellogg
>> Sent from my iPhone
>> 
>> On Oct 18, 2011, at 2:24 PM, "Martin Hepp" <martin.hepp@ebusiness-unibw.org> wrote:
>> 
>>> Hi Gavin,
>>> thanks for raising this. But as far as I can see, this issue is "still pending review" and anyway just considered for RDF 1.1, so current SPARQL implementations will still break on this.
>>> 
>>> Anyway, in this respect I think it is important to find a way to indicate the language of the value for a "content" attribute in 
>>> 
>>> <meta content="xyz">
>>> 
>>> patterns in Microdata; I just found out that the language of the context will not be used by Microdata-to-RDF parsers.
>>> 
>>> Martin
>>> 
>>> On Oct 18, 2011, at 11:09 PM, Gavin Carothers wrote:
>>> 
>>>> On Tue, Oct 18, 2011 at 1:50 PM, Martin Hepp
>>>> <martin.hepp@ebusiness-unibw.org> wrote:
>>>>> Ah! Thanks! That is a bug in my RDFa example. In all GoodRelations examples, we use datatyping, except for xsd:string, because while this is theoretically needed, too, the distinction between plain literals and typed RDF literals with xsd:string as their type is hard to explain to practitioners.
>>>> 
>>>> The RDF WG has resolved to remove that distinction. "example" ==
>>>> "example"^^xsd:string the current working draft of RDF Concepts talks
>>>> more about this,
>>>> http://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal
>>>> 
>>>> Cheers,
>>>> Gavin
>>> 
> 

Received on Wednesday, 19 October 2011 07:15:38 UTC