2

Is there a best practice for defining a literal with a language tag and a gender declension?

I couldn't find if there is a native solution for this.

We're using SPARQL and TriG, so a pseudo example of what I'm trying to achieve would be (using TriG):

content:data2
  a k_content:Data;
  content:content "איך אתה מרגיש?"@he-male ;
  content:content "איך את מרגישה"@he-female .

Would @he-female / @he-male be a big no no? How did you address this?

unor
  • 92,415
  • 26
  • 211
  • 360
ueeieiie
  • 1,412
  • 2
  • 15
  • 42
  • 1
    language tags are used to encode the language of text in a literal, see [RFC 3066](https://www.ietf.org/rfc/rfc3066.txt) - It's indeed not used to encode any further knowledge about the string. In RDF this is usually done via blank nodes or any other intermediate node. I mean, it's basically an n-ary relation that you want to express. Sure, you could also use your own language tags. It's some kind of hack but as long as the SPARQL engine doesn't check for valid language tags, it will work – UninformedUser Jan 31 '19 at 14:16
  • @AKSW Is there's a non-hacky way to address this? – ueeieiie Jan 31 '19 at 15:16
  • 1
    As I said, n-ary relations in RDF given that literals can't be subject of an RDF triple. – UninformedUser Jan 31 '19 at 17:31

2 Answers2

3

As @AKSW suggested one approach is using an intermediate node

content:data2
  a k_content:Data;
  content:content [
     rdf:value "איך אתה מרגיש?"@he ;
     content:declension gender:male
  ];
  content:content [
     rdf:value "איך את מרגישה"@he;
     content:declension gender:female
  ]

Another approach is to use dedicated (sub-)properties:

content:data2
  a k_content:Data;
  content:content-male "איך אתה מרגיש?"@he ;
  content:content-female "איך את מרגישה"@he .

The ontology (T-Box) could contain the following:

content:content-female rdfs:subPropertyOf content:content .
content:content-intersex rdfs:subPropertyOf content:content .
content:content-male rdfs:subPropertyOf content:content .
Reto Gmür
  • 2,497
  • 1
  • 20
  • 25
1

I agree that label characteristics should be stored in separate fields. The Lemon ontology provides appropriate fields, and the OLIA and GOLD (ISO DCR) provide values. (OLIA probably also has appropriate fields)

Vladimir Alexiev
  • 2,477
  • 1
  • 20
  • 31