[rdf12-concepts] Outsider's Thoughts

Hello,

I'm just an outsider that has recently seen that there is work on
an RDF 1.2 going on and that this new version contains
a new construct called a "triple term", which might be an object,
although another document, I think for N-triples or N-quads also
permitted it as a subject.

I have also read a bit of messages in this mailing list
and would like to share my thoughts.

I would propose to define an RDF term as one of either:
a blank node, an IRI, a triple term, or a literal.

Then define an RDF triple to be a tuple of 3 RDF terms:
a subject, a predicate and an object, with no further resrictions
on syntax, but rather say that it is undefined how to interpret
a predicate that is a literal, for example.

Then an RDF graph is a set of RDF terms plus a list of
references to them that asserts them,
making them into RDF statements.

This would allow to make statements such as:

    :S [ lpg:onProperty :P; :propC "C" ] [ :propD "D"] .
    :S :propA "A" ; :propB "B" .

    lpg:Resource a rdfs:Class ;
     rdfs:subClassOf rdfs:Resource .

    lpg:Property a   rdfs:Class   , rdf:Property ;
     rdfs:subClassOf lpg:Resource , rdf:Property ;
     rdfs:domain lpg:Resource ;
     rdfs:range  lpg:Resource .

    lpg:onProperty a rdf:Property ;
     rdfs:domain lpg:Property ;
     rdfs:range  rdf:Property .

which models this LPG thing I have just read about, I believe.

You could also make statements such as:

    "apple"@en :translatesTo "jabłko"@pl .
    <<("apple"@en :translatesTo "jabłko"@pl)>> :accordingTo :Me .
    :NotMe :disagreesWith <<("apple"@en :translatesTo "jabłko"@pl)>> .

A named graph is represented as:

    :graph :contains <<( :a :b :c ; :d :e , :f )>> .
    :graph :asserts  <<( :a :b :c )>> .

which parses into:

    :graph :contains <<( :a :b :c )>> .
    :graph :contains <<( :a :d :e )>> .
    :graph :contains <<( :a :d :f )>> .
    :graph :asserts  <<( :a :b :c )>> .

et cetera...

Implementation-wise, it's easier to parse since all terms have the
same syntax and internal structure after parsing.
I think it would be generally easier to work with such a structure.

In the future more types of terms could be added if needed.

Just my two cents,
Tomasz
Bye and have a nice day.

Received on Thursday, 2 May 2024 16:09:10 UTC