On 2013-11 -23, at 12:21, Andy Seaborne wrote:
>
>
> On 23/11/13 17:01, David Booth wrote:
>> [...]
>> This would have been fixed if the RDF model had been changed to
>> represent the language tag as an additional triple, but whether this
>> would have been a net benefit to the community is still an open
>> question, as it would add the complexity of additional triples.
>
> Different. Maybe better, maybe worse.
>
>
> Do you want all your "abc" to be the same language?
>
> "abc" rdf:lang "en" .
>
> or multiple languages:
>
> "abc" rdf:lang "cy" .
> "abc" rdf:lang "en" .
>
>
> ?
>
> Unlikely - so it's bnode time ...
>
> :x :p [ rdf:value "abc" ; rdf:lang "en" ] .
The nice thing about this in a n3rules-like system (where FILTER and WHERE
clauses are not distinct and some properties are just builtins) is that
rdf:value and rdf:lang can be made builtins so a datatypes literal can behave
just like a bnode with two properties if you want to.
But I have always preferred it with not 2 extra triples, just one:
:x :p [ lang:en "cat" ]
which allows you also to write things like
:x :p [ lang:en "cat"] , [ lang:fr "chat" ].
or if you use the ^ back-path syntax of N3 (which was not taken up in turtle),
:x :p "cat"^lang:en, "chat"^lang:fr .
You can do the same with datatypes:
:x :q "2013-11-25"^xsd:date .
instead of
:x :q "2013-11-25"^xsd:date .
I suggested way back these properties as a way of putting the info into the
graph
but my suggestion was not adopted. I think it would have made the model
more complete which would have been a good think, though
SPARQL would need to have language-independent query matching as a special
case -- but
it does now too really.
(These are interpretation properties. I must really update
http://www.w3.org/DesignIssues/InterpretationProperties.html)
Units are fun as properties too. http://www.w3.org/2007/ont/unit
Tim
>
> Andy
>
