-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
new doc that introduces properties related to well-formedness #117
Conversation
* If *s* is an IRI or a blank node, *p* is an IRI, and *o* is an IRI, a blank node, or a literal, then (*s*, *p*, *o*) is a triple term. | ||
* If *s* is an IRI or a blank node, *p* is an IRI, and *o* is a triple term, then (*s*, *p*, *o*) is a triple term. | ||
* If *s* is a triple term, *p* is an IRI, and *o* is an IRI, a blank node, or a literal, then (*s*, *p*, *o*) is a triple term. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason this not also true?
* If *s* is a triple term, *p* is an IRI, and *o* is an IRI, a blank node, a literal, or a triple term, then (*s*, *p*, *o*) is a triple term.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
**Definition:** An **RDF triple** (usually called "triple") is a 3-tuple (*s*, *p*, *o*) where: | ||
|
||
* *s* is an IRI, a blank node, or a triple term, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The abstract data model should not be extended to allow triple terms in the subject position.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is good to have a document that enumerates all the possible syntactic properties.
The document discusses triple-terms in section Triple-Term-Placement Well-Formedness.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The abstract data model should not be extended to allow triple terms in the subject position.
For this document, I thought it is useful to go back and use the least restrictive model as the basis, to then define the different possible syntactic restrictions on top of it. I admit, however, that the notion of triple-term-placement well-formedness that I had defined is mixing two separate things; namely the question whether triple terms can be used in the subject and the question whether a triple term in the object requires the predicate to be rdf:reifies
. So, in the spirit of trying to capture all possible restrictions separate from one another, I have changed this part of the document by splitting the earlier-defined notion of triple-term-placement well-formedness into two separate new notions: triple-term-subject well-formedness and triple-term-object well-formedness.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we have have general purpose reification, it's odd to restrict the usage of triple terms in "helper" ways. Maybe we need "advisories", which is weaker than well-formedness ("implementations SHOULD warn and SHOULD accept").
Even then:
<<( :s :p :o )>> rdf:type rdf:Triple .
<<( :s :p :o )>> skos:prefLabel "Appearance" .
Having these definitions is useful to bring out all the cases:
:myProperty rdfs:subPropertyOf rdf:reifies .
:r :myProperty <<( :s :p :o )>> .
It occurs to me that the notion of well-formedness that the group strives for has more facets than just the decision of whether
rdf:reifies
is many-to-many or many-to-one, and I think it would be useful for us to be able to discuss and to decide about these facets independent of one another. Therefore, I have created a document in which I define different syntactic properties that an RDF graph with triple terms may possess, where each of these properties corresponds to one of the facets that I see. The important point is that these properties are completely orthogonal, and we can decide which of them we include as the properties required for well-formedness.