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

On 01/06/11 07:43, Ivan Herman wrote:
> Andy,
>
> On May 31, 2011, at 19:28 , Andy Seaborne wrote:
>
>>
>>>>> Modelling everything at a very fine grained level moves the
>>>>> burden on to the application.
>>>>>
>>>>> c.f. RDF containers and collections.
>>>>
>>>>
>>>> Conditionally, yes. It would only arise when language tags are
>>>> used. Most strings do not use language tags.
>>
>> 1/ We find that there can be very lang-tag intensive datasets.  For
>> example, data from Wales.
>>
>> 2/ Don't we have a new variability to deal with:
>>
>> <s>  skos:altLabel [ a rdf:LinguisticExpression; rdf:language
>> "bar"; rdf:value "foo"] .
>>
>> <s>  skos:altLabel "foo" .
>>
>>
>> And
>>
>> {<s>  skos:altLabel ?altLabel }
>>
>> get us back to same problems of RDF collections and a round trip to
>> get the next step in the information (assuming skolemization).
>>
>>>> The question is, IMO, whether the benefit of fixing the
>>>> equivalences between RDF strings is worth the pain to be
>>>> experienced by users of language tags in this context.
>>>> *Personally* I would rather query the above pattern than need
>>>> to guess whether a string is a plain literal or a language
>>>> tagged string or an xsd:string.
>>
>> Not sure it's a guess unless we do nothing.  At least they are all
>> a single RDF term that can be queries then inspected.
>>
>> People here seem to want a datatype for all literals.
>>
>> If every plain literal now has a datatype, xsd:string or
>> rdf:LangString (or other name), and use LANG knowing that
>> rdf:LangString  means use LANG to ask further i.e. Value space of
>> ("foo", "en").
>>
>> rdf:lang-{langTag} requires dereferencing to get the language (or
>> IRI mangling but maybe some invented a different IRI - no unique
>> names here!)
>
> Just to check my understanding; what you are saying is:
>
> - if one goes along the lines originally proposed by Richard, ie,
> using rdf:LangString (or some similar name) then any SPARQL query
> involving a language becomes a bit cleaner because one can use
> lang(?v) in a FILTER or (in SPARQL 1.1) in an AS; whereas

Yes, marginally.  The "bit" is quite small - it's nicer that 
datatype("foo"@en) is defined by a spec and not an error in base SPARQL.

An app interested in language tags will just look for language tags 
using LANG:

{ ?s skos:prefLabel ?label
   FILTER (LANG(?label) != "cy")
}

(Adding isLiteral() is probably unnecessary from context)

LANG(literal) in SPARQL return "" (c.f. xml:lang="") on a literal with 
no language tag.

SPARQL has three accessors to the 3 parts literals - lexical form, 
datatype and language.

 >
> - if one
> defines a series of rdf:Lang-{langname} then queries (or
> applications) will have to fiddle around interpreting the URI-s.
>

It does look like detailed datatyping on languages does not help.

If that is the only way to get the language, it's ugly but if the value 
space is defined as xsd:string union ("lex", "lang") then define LANG to 
access the second part and there is no help given by the datatype. 
Easier and more direct to use LANG than interpretlang-datatypes.

> And that is quite a compelling argument against rdf:Lang-{langname}
> to me, I must admit

I agree.

Language tags for apps that care matter to the point where the fact they 
are handled as language tags and not as part of a larger framework isn't 
important.  The rdf:Lang-{langname} proposal does not help in processing 
the relationship between language tags and I think we have concluded 
that datatypes are not the right modelling for such relationships.

	Andy

> Ivan
>
>
>>
>> Andy
>>
>>
>>>>
>>>> Regards, Dave
>>>>
>>>>
>>>>
>>>>>
>>>>> Andy
>>>>>
>>>>
>>>
>>
>
>
> ---- Ivan Herman, W3C Semantic Web Activity Lead Home:
> http://www.w3.org/People/Ivan/ mobile: +31-641044153 PGP Key:
> http://www.ivan-herman.net/pgpkey.html FOAF:
> http://www.ivan-herman.net/foaf.rdf
>
>
>
>
>

Received on Wednesday, 1 June 2011 08:04:23 UTC