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

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.
(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 <mpol@meep.pl> wrote:
> 
> On Fri, 23 Nov 2018 13:16:02 +0000, Hugh Glaser wrote:
>> 
>> 
>>> On 23 Nov 2018, at 12:57, Frans Knibbe <frans.knibbe@geodan.nl> 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 <hugh@glasers.org>:
>>> 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 Friday, 23 November 2018 20:31:19 UTC