Quad.php: Subject must be of type NamedNode or BlankNode

[k00ni]

Other types of Term as subject are not allowed in quads, ref RDF 1.1: https://www.w3.org/TR/rdf11-concepts/#section-triples

[zozlak]

When it comes to subject and object things are difficult:

• Subject can always be a BlankNode or NamedNode and always can't be a Literal
• Object can always be a Literal, BlankNode or NamedNode

But this is an open-ended definition with other entities being allowed as subject/object by various RDF extensions, e.g. RDF* or N3 notation and we can't really say the subject has to be a NamedNode or BlankNode. (btw theoretically this issue can affect also predicate and graph but it looks like in practice no one saw a need to extend these them).

There are two ways to model it:

• Explicitely by introducing SubjectTerm extends Term and ObjectTerm extends Term interfaces.
• By taking the "duck typing" approach, setting both subject and object just to Term and leaving it up to the implementation to rise exceptions when subject/object incompatible with particular implementation is passed to it.

The first solution looks nice at the first glance. But there are a few concerns. These interfaces won't bring any additional methods and while Literal can extend ObjectTerm, BlankNode and NamedNode can't because we only have single inheritance in PHP and they would need to extend both SubjectTerm and ObjectTerm. It means at the end of a day only implementations will be able to use these specialized interfaces (as class MyNamedNodeImplementation implements SubjectTerm, ObjectTerm {...}) which is not very useful as these interfaces don't define any methods. And when it comes to classes/methods consuming subjects and objects (e.g. Quad and QuadTemplate) in most implementations they won't be able to deal with just any SubjectTerm/ObjectTerm but only subsets of them a given implementation supports (e.g. if an implementation provides only basic RDF triples it will be just BlankNode/NamedNode for subject and BlankNode/NamedNode/Literal for object). So all in all with explicit definition of subject and object we are just adding boilerplate without any practical use.

Therefore I decided it's better to leave it just to Term in the interface definition and let the more strict types checking up to particular implementations.

Please feel free to disagree. Discussing topics like this one is crucial to end up with a good interface.

[k00ni]

I was not aware of the fact that in further RDF extensions the subject can be something else. Its OK for me and I agree with your concerns.

By taking the "duck typing" approach, setting both subject and object just to Term and leaving it up to the implementation to rise exceptions when subject/object incompatible with particular implementation is passed to it.

Its a good way to go. Its still RDF, but we allow developers to vary their implementation.