Re: "Language-tagged strings Re: Toward easier RDF: a proposal"

Op vr 23 nov. 2018 om 21:35 schreef Hugh Glaser <>:

> Ah, absolutely right.
> Thanks.
> I was trying to create the equivalence of the @, but failed.
> > If "shower" and "shower" are not English nouns but just strings,
> > then they aren't English anything, are they?
> Firstly I guess that "shower"@en and "shower"@en-us are different strings,
> so my suggestion is not equivalent.

Just for clarification, and as an aside: I thought the example of "shower"
was interesting because the way it can be understood does not depend only
on language, region or syntactical context. If it is pronounced one way, it
means something that makes you wet. When pronounced in another way, it
means someone that is showing something. I am not a native English speaker,
but I think you should hear the sentence "My niece showed me her drawing of
a shower" being pronounced to get an idea of its meaning.


> (Although I guess that datatypes can be split out without changing the
> meaning.)
> I do think of "shower" as a collection of letters that happens to be a
> word (or words) in English.
> And in that sense both the @en and an RDF property say the same thing (I
> think!).
> But actually it does bring up some interesting issues.
> It might be a good thing.
> To elaborate, if I am using a resource about, say, Mozart, it is likely
> that there will be dozens of rdfs:label (and foaf:name and skos:prefLabel
> etc.), one for each language (actually we should be saying locale) provided.
> In the normal way of modelling this, each of the different language
> strings will be different.
> Is it possibly better to have a single instance for each unique string
> rendering, and associate locales with it?
> Having things separate and more easily SPARQLable can be easier.
> It is much easier to choose languages, and one could for example easily
> find out which are the most common renderings, or list all the different
> renderings.
> Best
> > On 23 Nov 2018, at 13:59, Michal Politowski <> wrote:
> >
> > On Fri, 23 Nov 2018 13:16:02 +0000, Hugh Glaser wrote:
> >>
> >>
> >>> On 23 Nov 2018, at 12:57, Frans Knibbe <> wrote:
> >>>
> >>> Using a general way to make statements about literals sounds good to
> me. For geographical data I also see too many statements being squashed
> into a single literal.  It is difficult to process and to store.
> >>> Extensibilty could also be an issue. Why have a standard provision for
> indicating the language of a text string and not its pronunciation for
> example? How else can we tell the difference between the English nouns
> "shower" and "shower"?
> >>
> >> "shower" and "shower" and not English nouns - they are strings, and
> both the same.
> >> If you want the English nouns, you should be using URIs for the nouns,
> which possibly have that string attached.
> >> Similarly, strings don't usually have pronunciations - things
> associated with strings do.
> >> (My three ha'p'orth, others' mileage may vary.)
> >
> > Ah, but if literals are 1 component things and a string is just a string,
> > then what would one state by using RDF properties for eg. languages?
> >
> > If "shower" and "shower" are not English nouns but just strings,
> > then they aren't English anything, are they?
> >
> >>> Op vr 23 nov. 2018 om 13:07 schreef Hugh Glaser <>:
> >>> Ah, good topic.
> >>>
> >>> So another thing I don't understand (:-)) is why we have to have
> language tags on strings at all, and indeed datatypes.
> >>> (OK, it's because of XML heritage or something, I guess.)
> >>> But we have a perfectly good way of representing knowledge about
> things.
> >>> It is a real pain to create these 3 component literals and to query
> for different languages and datatypes in SPARQL.
> >>> And worse still, if you want to query for strings that may or may not
> have language tags on, you need to do some real messing about.
> >>> I often end up adding @en to all the strings, or removing region tags
> etc., just so I can do things more easily, which is surely a Bad Thing.
> >>>
> >>> Surely languages and datatypes should simply be RDF properties of
> Literals, which are 1 component things?
> >>> Much easier to explain to developers, and for them to use.
> >>> (If indeed they want to use raw RDF.)
> > [...]
> >
> > --
> > MichaƂ Politowski
> >
> --
> Hugh
> 023 8061 5652

Received on Saturday, 24 November 2018 14:22:42 UTC