Re: Reference versus xsd:anyURI Literal in JSON-LD

I think we can avoid this by not requiring any such language in the spec. The @iri datatype in @coerce is necessary to describe the value as an IRI, but from a JSON perspective, everything else can just be native JSON types (i.e., String, Boolean, and Number (both be Integer and Fixed) without an @coerce mapping. Assigning a type IRI to some representation of the literal can be left to a separate JSON-LD to RDF (or whatever) mapping. The @coerce rules just associate a type IRI with the value, so it's consistent with using XSD datatype definitions, but could also be used with schema.org datatype definitions (e.g, http://schema.org/Date) or something else entirely.

Gregg

On Jul 10, 2011, at 10:26 PM, Markus Lanthaler wrote:

>> My interpretation of the RDF WG's recommendation is that we could use
>> xsd:string to refer to string literals without a language and
>> rdf:PlainLiteral to refer to literals that may have a language but not
>> a datatype. rdfs:Literal denotes a literal that may have either a
>> language, a datatype or neither.
>> 
>> The only reason to use something like "@literal" would be to avoid
>> introducing RDF terms, but semantically I think they're describing much
>> the same thing.
>> 
>> Your use of "@literal" is effectively the same as "xsd:string", in
>> which case I'd just use that. If we need to say something about
>> literals that don't have a datype, we could use rdf:PlainLiteral, but I
>> don't see why this is necessary.
> 
> I would really favor to remove those XSD datatypes from the spec altogether.
> Why should be create "dependency" on XSD for a approach based completely on
> JSON? Is there any advantage of doing so?
> 
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
> 
>

Received on Monday, 11 July 2011 16:35:16 UTC