-
Notifications
You must be signed in to change notification settings - Fork 3
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
Define an interpretation of Triple Terms #49
Comments
For the linked use case, this may not be necessary to define in RDF semantics. The use case does rely on OWL, so it arguably belongs in a semantic extension in that layer. OWL does have its own reification of sorts (using As an alternative, this interpretation could be added to the semantic extension defined in RDF Schema 1.2 instead. A connection to unstarring appears valuable; and so unstarring could be based on such RDFS terms instead. Having that would be enough to be able to use unstarred forms with existing tooling, and then later on upgrade an OWL2 reasoner to support RDF Schema 1.2. (As a minimum aid for interoperability, an informative section about the semantic extension might do. Or even more minimum, a separate Note. I volunteer to make a PR for anything we agree upon.) |
This interpretation entails a blank node which denotes the same resource as the triple term (would be That is what is currently discussed for unstarring, and fully represents multiple triples for the same reifier ( The semantics in the agreed transparent baseline says:
which may allow this interpretation? If not, then maybe an extension (perhaps in RDFS) is still acceptable? |
This was discussed during the rdf-star meeting on 26 September 2024. View the transcriptDefine an interpretation of Triple Terms 5niklasl: I propose to use the rdf:subject/predicate/object properties for the interpetation niklasl: This might not good to entail old reification from triple terms <Zakim> pfps, you wanted to ask how this relates to the semantics from Enrico? <niklasl> w3c/rdf-ucr#27 <gb> Issue 27 Integrating different ontology designs through entailment upon triple terms (by niklasl) [use case] <pfps> Where are the semantics from Enrico, by the way? ora: If we need some clarification on this, does it means we differ this one until Enrico shows up? pchampin: Does this point to a specific use case or is this a nice to have, niklasl: there are use cases I defined previously AndyS: This seems to relate to the discussion around unstar AndyS: Done this way I don't see how we can add multiple triples to the same reifier tl: I have developed in a github issue multiple variants and they are all many-to-many one is RDF-vocabulary based <niklasl> Here is a comment on the unstarring issue I made yesterday w3c/rdf-star-wg#114 (comment) which relates to this issue about interpretation. <gb> Issue 114 Un-star operation to support RDF Dataset Canonicalization? (by niklasl) [needs discussion] [discuss-f2f] ora: I don't think we can reach a concensus here, is it a good discussion topic for next week after voting? <Zakim> tl, you wanted to ask about when rdfs:states will be discussed <gkellogg> JSON-LD-star slides – https://json-ld.github.io/w3c-tpac-2024-presentations/json-ld-star/ <AndyS> +1 to having the JSON-LD presentation in a focused meeting. ora: Thank you everybody |
@niklasl Your linked use case is concerned with reifiers: occurrences of an abstract triple, and their attributes. I agree that the conversion you describe is an important use case, but isn't this in essence the same issue both as the unstar operation and the desire to refer to individual nodes in a reified term? It seems to me like all these use cases that in one way or another need to refer to the individual parts of a reified triple term can be addressed with the RDF standard reification vocabulary. I'm waiting for @franconi to confirm, or comment (because he seemed to see an issue about reusing that vocab, but maybe I misunderstood). However, describing an abstract triple term itself is a different use case (and I have yet to see a compelling example). I'm reluctant to re-use the RDF reification vocabulary also to describe abstract triple terms, but if this as niche a use case as it currently seems, then maybe there is not much harm to be expected. However, defining the |
As discussed in the Semantic TF meeting on 2024-10-18, using new terms is likely necessary. I'll update the issue text with such (provisional) terms, to be aligned with what is possibly defined for w3c/rdf-star-wg#114. |
1::
This needs to be updated to include triple terms. 2::
it would be useful to have text in RDF Semantics saying "A triple term denotes ..." |
Triple terms are new in RDF 1.2. Both formally, and in order to leverage implementations adhering to the existing RDFS and OWL 2 standards, an interpretation of triple terms that entails relations to its constituent terms appears to be needed.
An example of this need is illustrated in w3c/rdf-ucr#27.
I think a suitable interpretation been proposed before by @Antoine-Zimmermann as "RDF-reification interpretations". That also defines how the constituents act as a key for the triple term resource. (This proposal was also referenced in the "Seeking Consensus" table from 2024-01 in the row for the agreed upon Option 3, as an interpretation variant.)
This interpretation is not needed in the basic RDF semantics, but would be useful as an extension to be used together with OWL.
Looking at the RDF entailment section, I'm thinking this may be a start:
(A note on triple term denotation similar to the one about literals appears to be valuable too.)
With such an interpretation in place, it seems valuable to define "unstarring" using the chosen
rdf:type
and predicates for the entailed triple term resource description.(See also w3c/rdf-star-wg#127, which is of relevance to
aaa
in the above pattern.)Note
Edits to proposal:
The exact name of the class of triple terms (here,rdf:Triple
) is to be debated. If the "classic reification" properties (rdf:subject
,rdf:predicate
,rdf:object
) are chosen, thenrdf:Triple
is reasonably a subclass ofrdf:Statement
, since that is their defined domain.(Note: While it is not necessary to reuse those properties, it seems frugal to do so. But if there are reasons for minting new properties, that would also work.)The text was updated successfully, but these errors were encountered: