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

Re: getting language tags out of the fundamental model (ISSUE-12)

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 31 May 2011 17:04:50 +0100
Message-ID: <4DE511A2.9070704@epimorphics.com>
To: public-rdf-wg@w3.org

On 31/05/11 15:17, Sandro Hawke wrote:
> I'm happy with the rdf:string-{Lang} datatype design, but if that seems
> inelegant to you....
> On Fri, 2011-05-27 at 12:32 -0500, Pat Hayes wrote:
>> Now we are proposing to bury one of them inside a URI to get rid of
>> it. I would vastly prefer that we simply accepted that some literals
>> have more than one string, and adapt our notion of literal typing to
>> accommodate to that fact, rather than trying to disguise it or pretend
>> its not true, and so become obliged to swallow some clearly artificial
>> notion (such as a language tag being a kind of datatype) just to
>> preserve what is in any case a purely arbitrary model of literal
>> typing.
> In that vein, I think the *clean* thing to do with language tagged
> literals is to get them out of the fundamental model.  RDF can model
> anything, so it can certainly model strings with language tags.
> Anything else is an optimization, I think, put in place for folks who
> think language tagged strings are so common they need special support.
> Then the question is what they really need (conceptual simplicity for
> humans, nice syntax, efficient machine processing, ...?), and what does
> the least damage to anything else....
> In other words, we could say "foo"@bar is syntactic sugar for something
> like [ a rdf:LinguisticExpression; rdf:language "bar"; rdf:value "foo"].
> I know that doesn't address everything, but it has pretty much the same
> problems everything else does being modeled in RDF.  :-)
>      -- Sandro

Modelling everything at a very fine grained level moves the burden on to 
the application.

c.f. RDF containers and collections.

Received on Tuesday, 31 May 2011 16:05:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:07 UTC