what properties can or should link to triple terms? #127
Comments
|
Hi Andy
Based on my recollection of the meeting, I think that option 2.ii) could be further subdivided into:
- A well-formedness requirement, i.e., well-formed RDF would only allow an object triple term with predicate rdf:reifies (this was introduced before my time at the WG, so unsure about the details); or
- Assigning a range of class "TripleTerm" to the reification property (ies). Gregg Kellogg suggested this option.
W
… On Sep 13, 2024, at 12:38 PM, Andy Seaborne ***@***.***> wrote:
Wiki page:
Notes from the Semantic Task Force meeting 2024‐09‐13 <https://github.com/w3c/rdf-star-wg/wiki/Notes-from-the-Semantic-Task-Force-meeting-2024%E2%80%9009%E2%80%9013>
The wiki page will be revised based on any discussion on this issue.
Minutes:
https://www.w3.org/2024/09/13-rdf-star-minutes.html
—
Reply to this email directly, view it on GitHub <#127>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2PLMB6NXKDTK5RJEPP5FLZWMIHFAVCNFSM6AAAAABOFW3YZOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGUZDKMRTGQ2DKNI>.
You are receiving this because you are subscribed to this thread.
|
|
Hi @william-vw, The well-formedness approach is available via the sidebox on the wiki page but I've added links to a few relevant pages at the bottom of the "notes" wiki page to be more obvious. The "alternative baseline" and The range constraint could go into RDFS but, as mention in the meeting, we are dealing with base RDF. The text note quoted from RDF Concepts contains the current way to express it at the RDF level. Presumably this could be reflected in RDFS and in the RDF namespace document. The WG may wish to upgrade the "note" to more formal text in RDF Concepts or RDF Semantics. |
|
@afs note that I wasn't saying that the well-formedness approach was not visible in the wiki, or that I am necessarily advocating for an RDFS range (or even starting this discussion). This was just my recollection - which may be faulty - of 2 "sub-options" proposed in the meeting :-) |
|
How would sub-properties of |
|
In 2.ii, the class
Having other properties, which may be subproperties of It is a way of having the effect of the condition in "minimal-baseline" within the idea of metamodelling with |
ktk
added
the
discuss-f2f
|
This was discussed during the rdf-star meeting on 26 September 2024. View the transcriptMaterial about rdf:ReificationProperty 3AndyS: there is a not of the Semantics TF meeting, Friday 13 September. AndyS: I think the key point in there is that there are really only two options. Intermediate optiosn do not work out. pfps: I believe this discussion should be deferred until we have several reifying properties. <Zakim> gkellogg_, you wanted to point out that rdf:ReificationProperty is not a property, but a class. Perhaps there's a better name to use. gkellogg_: noting that ReificationProperty is not a property but a class. Naming it that way can be confusing. <AndyS> +1 to renaming -- e.g. "rdf:ReificationPropertyClass" tl: I'm promoting that other reification properties exists (e.g. rdfs:states), but I would also let anyone define their own reification properties. <niklasl> The name does follow the naming pattern of rdf:Property, owl:ObjectProperty, owl:DatatypeProperty though? <pfps> Oops, in trying to set up my headphone, I cut off all sound. <pfps> I note that rdf:type is not a member of a class. ora: about the name: yes it is a class, but we have other classes whose name ends with "Property" (rdf:Property, owl:TransitiveProperty) <doerthe> I think pfps should go first AndyS: I agree that there are others <niklasl> rdf:type a rdf:Property # ? pfps: I don't see why we need to do this. rdf:type is special, it does not belong to a class. <doerthe> isn't rdf:type an rdf:Property? <tl> @pfps the reason is that we want to somehow describe how to use triple terms doerthe: isn't rdf:type an rdf:Property, not a specia one, but still a property. <AndyS> rdf:ReificationProperty -- https://github.com/w3c/rdf-star-wg/wiki/RDF-star-%22alternative-baseline%22#metamodelling-entailment-patterns-and-axiomatic-triples doerthe: The goal of ReificationProperty was to help people find out that a property was used with a triple term as object. Not more, not less. <william_vw> thanks everyone - I need to leave to attend a school assembly here pchampin: -1 to rename rdf:ReificationProperty to rdf:ReificationPropertyClass. Names matter. <tl> +1 to that ora: what is the hypothetical effect that this has on implementers? pchampin: In my opinion it doesn't give more or less latitude to implementors. AndyS: IIRC ReificationProperty was introduced by Enrico to replace the well-formed-ness condition. ora: if rdf:reifies is a special property, similar to rdf:type, do we have examples or subproperties of rdf:type? gkellogg_: Schema.org defines a subclass of rdf:type. <niklasl> Yes, schema:additionalType is explicitly defined as rdfs:subPropertyOf rdf:type tl: I like the idea of using rdfs:subPropertyOf niklasl: I am not sure what I think about the subProperty solution. I also concur with AndyS. doerthe: I don't have an opinion yet about the subProperty solution. I don't know what it would do. <AndyS> It's not range but RDF concepts (editors working draft) has https://www.w3.org/TR/rdf12-concepts/#h-note-2 gkellogg_: I think we have discussed having a range for rdf:reifies of rdf:TripleTerm. <doerthe> I am just afraid that we add a triple term class and make it the range or rdf:reifies gkellogg_: the type rdf:TripleTerm is used to indicate that a blank node is representing a triple term. niklasl: I agree. There was a discussion about naming it rdf:Triple vs. rdf:TripleTerm, but that's a separate discussion. gtw: I mentioned SPIN before, where you don't necessarily want to set a range. doerthe: the moment we set a range on rdf:reifies, I would disagree with the subProperty solution. <MacTed> rangeIncludes ? pchampin: I agree with doerthe and would vote against my own proposal if we have a range for rdf:reifies. niklasl: we haven't talked about what Reification Property would mean. TallTed: it occurs to me that this may be a place where schema.org's rangeIncludes and domainIncludes can be useful. <tl> I had that discussion with Greg Williams and though that when mixing ways to represent triple terms it's not surprising that issues occur. Apart from that, maybe I'm just ignorant so I would like to see examples from e.g. Dörthe TallTed: These are not enforced schemata. ora: I feel we should hear Enrico on this. Let's encourage him to read the minutes, and pick this up next Thursday. pchampin: +1 <niklasl> +1 <tl> +1 <TallTed> we should perhaps close the items we've addressed (e.g., un-star)? |
|
Define an interpretation of Triple Terms #49 gives an example where:
So I'm again leaning towards the position that we should just say something to the effect of:
|
gkellogg
removed
the
discuss-f2f
|
This issue is basically about what properties are allowed to link to triple terms. The major decision is whether there is only one property that connects to triple terms ( The first alternative would require that the only links to triple terms are for the The second alternative would allow other properties as well, like Note that the details of the syntax are not important in the examples above. All that matters is the resultant RDF 1.2 graph. (markup edited for clarity by @TallTed) |
|
IMO the first alternative is too restrictive, and that restriction is also easy to work around (probably too easy if one subscribes to the restriction). The minutes of the 25.10.24 Semantics TF meeting discuss some interesting aspects. What strikes me in particular is that even if the specification allows to refer to triple terms only via the A Reification has a very general semantics, and it seems that all useful references to it a triple term can be defined as specializations of reification. What properties could there be that would be impossible to define as subproperties of Here, If it's not even possible to sensibly assume that all references to triple terms reify the triple term, then what is there left to define? Maybe just this:
|
pfps
changed the title
rdf:ReificationProperty
pfps
changed the title
|
EDIT: To avoid confusion, I updated all subsequent posts to use This is a general comment on how nesting triple terms may be a more verbose (but possibly simpler) alternative for reifiers. I wasn't being very specific with the particular notation; and it abstracts from current translations using reifiers. From today's meeting, I understood that reifiers are quite useful to group metadata that follows a different "interpretation" or "context". E.g., This way, we still know which people found the belief to be true or false. Making a parallel with conceptual modeling, where you essentially draw circles around stuff to reify them ( I.e., we draw an extra circle around the extra "context" ( The ordering will be very relevant here ; it will depend on the desired context. If the desired context is (This will also require extra reifiers to distinguish between bob/alice, etc. I am just pointing this out to say that ordering will have an impact.) I can also imagine cases where multiple contexts will require multiple levels of nesting: Becomes (as a triple term cannot include property and object lists :-)): There are clear practical limitations to this approach. I am posting this to find out whether there are any other non-practical issues with this. |
TallTed
changed the title
|
Triple terms are
The first example is triple terms I don't know about the rest. Did you mean
This different from #132 where the discussion is more about compound form in occurrences A triple term can't have compound components because it is for a triple - 3 RDF term components. |
|
@afs Thanks. I wasn't specifically targeting Turtle or N-Triples. This is a general comment on how nesting triple terms may be a more verbose (but possibly simpler) alternative for reifiers. I wasn't being very specific with the particular notation; and it abstracts from current translations using reifiers. Re:
I thought I had seen examples with nested triple terms before, but I double checked the grammar: Note that my post also draws into question this restriction of triple terms to object position. |
|
Then some questions for clarification: What does Does The simplification we have so far is that triple terms are expected to be largely unused except for use with We have also tried to only have named occurrences - but then how can you ask "what is the subject of this occurrence?" That is a function/map from occurrences to the elements of the triple. In that sense |
I did not put a lot of thought into the predicates.
Yes
Just so we are on the same page: a triple term allows describing a triple (that may be member of the graph, or not). E.g., Describes the triple The following: Describes the triple The nesting of the triple term I understand reifiers here as a mechanism to group metadata under a particular interpretation / context (see my original message); and this mechanism involves creating a "token" or "occurrence" of the triple term. I'm simply wondering whether there are other / simpler mechanisms to do the same. If so, then it's perhaps not a good idea to impose restrictions in line with only one of several ways of grouping metadata under a particular context. |
Then it is the same as: and it seems to me that the complexity is still there, it's been moved into the definition of the predicates because they say time of use (context), and it's not a direct description of the triple itself. I'm not sure trees are the only shape of context.
Understood! |
Unsure what point you are making, as this was not one of my examples :-) In the prior example, I believe all the outer triple terms were unique: But, if you simply want to say that the outer triple was recorded at time 123 and 456, then your example would work. If you want to say something about the outer triple being recorded at time 123, then: You can simply put an extra I'm unsure what you mean by:
Neither are reifiers, I think; they are simply associated with / tokens of (depending on who you're talking to :-) triple terms, which I am directly using above.
Hmm - since you can simply put |
I would say no, they're not equal. The
For this to be the case, you'd need to use explicit reifiers: Then you could reduce this to: |
|
For instance, consider @niklasl's Elizabeth Taylor example, where she married Richard Burton twice. In contrast to reifiers, when using nested triple terms, you have to choose what context to use for grouping metadata. We need two groups of metadata, i.e., one per instance of marriage between the two. We need a separate outer triple term per group of metadata, i.e., they need to be unique. We could choose This is clearly much more of a hassle compared to reifiers. You can simply create a new reifier for a separate group of metadata, without having to worry about uniqueness as above. This is really reminding me of primary keys in database modeling exercises ... Either create an artificial (e.g., auto-increment) primary key - which seems to be reifiers here - or select a primary key from existing attributes, which is seems to be the nested triple solution. Does anyone see any other issues? |
Apologies - I should have said from the beginning that I am abstracting from particular formats. I said the following in a prior response:
To avoid confusion, I took the liberty of updating all relevant posts with the appropriate notation. |
|
(well, reifiers could be better compared to primary keys if they were one
to one)
|
|
@william-vw, your example shows how you need to add additional levels of nesting annotations to make the (outermost) annotated triple term sufficiently unique. IMO this is unnatural and counterintuitive. There is a statement, and a set of annotations on it. Some of those annotations have more disambiguating power than others - the source's name in this case - but can and should an author be expected to think about such technicalities? To me it seems much more straightforward to just write and let the system add the necessary disambiguation (minting a blank node to name the reifier). It is actually pretty hard to come up with use cases that reliably and always only need to refer to the triple term itself: counting occurrences of triple terms is the only one that I find convincing. Idealized examples using triple terms either have only one annotation, or expect the triple term to occur only once, i.e. be unique in the graph. You have now found a way to stretch that uniqueness constraint - congratulations! ;-) But as I said above, I don't think this a natural way of modelling. Also it requires re-modelling when what was first thought to be unique needs disambiguation later on. Early disambiguation as in the occurrence-centered approach is the safer approach. In the CG we had a similar discussion w.r.t. the proposed |
Indeed and that is one of the points I was making.
You should congratulate @niklasl as this is from his example :-) I am sure that there are many, many other examples from database exercises, where students are asked to identify primary keys from existing attributes.
Congratulations - you just found one criterium for choosing primary key attributes :-) I was careful not to suggest this in lieu of reifiers, but rather as an alternative to achieve the same goal, i.e., grouping sets of metadata under the same context. Whether or not it is a natural way of modelling is up for discussion; the same for database modeling, where both approaches keep existing1:
Possible drawbacks of reifiers (greatly depending on the implementation) are that they require an extra lookup/join to find their associated triple term, and extra triples are needed to keep the association. If there are no other issues - aside from those already raised - then I would be apprehensive to impose restrictions that enforce reifiers (e.g., only allowing them in the object position). Footnotes
|
Or rather against them? Following that link I learn as "Criteria for Choosing a Primary Key":
...and stability is exactly the thing that we can not rely an, and that RDF is designed to not rely on. Also, and here comes the many-to-many design of reifiers into play, if one really wants to model in a relational style, wouldn't one rather create the key right away, make it the subject of a number of statements and then annotate it, e.g. That sure looks ugly ;-) but not uglier than repeated nesting.
My counter argument is still: RDF is a graph formalism. It can represent relational structures, but that's not where its strengths are. Regarding our task, standardizing a mechanism to easily make statements about statements, I consider it more important to foolproof the basic mechanism
An issue of your approach is that order becomes important. Slightly changing your example: Although I just switched the order of columns, so to say, two different keys have been generated. That doesn't seem desirable. Maybe it's okay in a relational system, but it seems quite surprising to RDF. It can even be read as two different things: a belief that Bob reported said marriage, or Bob claiming that said marriage is just a belief.
Souri, who has a strong RDBMS background, has been strongly arguing in favor of an occurrence based approach as it helps keeping queries valid even when data is updated. Implementation issues are not to be neglected, but usability can have a pretty decisive effect on overall performance.
Well, we had a years-long discussion about this. The fact that the seminal example (see the CG report) had the very defect that the type based design of triple terms is so prone to should tell you something. Granted, you are the first to convince me that there could be a more-then-unpermissible-simplistic application for triple terms in subject position. I'm still very much in favor of ruling it out. |
Note that relational databases are even less stable - one can remove & update prior rows, whereas RDF is monotonic, technically - and yet choosing primary keys from existing attributes has, at least, persisted there.
Honestly, I am a bit unsure what the impact is of the graph formalism. I was getting flashbacks from my days as a DB teaching assistant; this is why I made the analogy. I am not trying to impose a relational structure on top of RDF.
I feel that we are enforcing a particular design pattern, whereas RDF should be about flexibility (or so I keep hearing :-). For more complex use cases, reifiers can be used; for simpler ones, a triple term (or nested one) could be used. It is true that one can easily shoot themselves in the foot this way, as the Taylor + Burton example shows. But, people can already shoot themselves in the foot with RDF, very easily, as they can with databases and any other formalism. Should we enforce certain design choices?
Yes, this is a point I had made initially; ordering will be very relevant and will depend on the desired context. But, one could instead think about this in choices of reification (i.e., which statements you are reifying). Note that nesting triple terms is already possible beyond their use to group metadata. I am simply wondering whether this can serve as an alternative (not a replacement) to reifiers.
Yes, issues of stability remain. E.g., adding the extra marriage between Elizabeth Taylor and Richard Burton can easily gum up the works. E.g., given And then adding Will mean that we are no longer able to distinguish the metadata of the two marriages. While that is an issue with primary keys in general, one could indeed argue it is a bigger problem in an open world.
Note that this method uses existing constructs, namely triple terms - in a syntactically legal way - to create groups of metadata. If people strongly feel that it shouldn't be used, then perhaps a better solution is to not allow nested triple terms, unless they have other use cases. |
And I'm saying that it leads to a lot of trouble down the road, without tangible benefit.
Am I missing something? We're arguing about if triple terms should be allowed in subject position, right? If they are not, this is not syntactically legal.
That seems like an unnecessarily drastic step to me. What about chains of provenance, or annotations from different domains like qualification and administration? I wouldn't rule that out just because the design is focused on occurrences, not types. |
Ok, that is a fair opinion.
Yes, you are - I was referring to the fact that it is perfectly legal to nest triple terms. If the discussion is about restricting triple terms to the object position, examples to the contrary will have to assume that they are not yet restricted this way :-)
I feel this is making it even worse. In some use cases, it should be allowed to nest triple terms, but in other cases, it should be discouraged? And that is done by disallowing triple terms in a particular position, because we think that the latter case would mostly rely on that position? |
Are we still talking about the same thing? It seems to me like you mix triple terms, e.g.
What do you mean with "some cases". I'm talking about nesting triple terms in object position but not in subject position, nothing else.
Again, the argument is that almost all use cases talk about occurrences of triples, not about the type itself (very similar to RDF standard reification). The syntactic constraint is meant to prevent users from expressing something they don't intend to express, just because it's shorter, or seems natural, or unproblematic. |
Yes we are - no mixing up of triple terms with reifications. I clarified this in my initial post to avoid this kind of confusion as I had been a bit fast and loose before -
Why, the ones you had raised before :-) In some use cases, it seems it should be allowed to nest triple terms (your aforementioned cases); but in other cases, it seems it should be discouraged (grouping metadata). To achieve this, the proposal is to disallow triple terms in a particular position (subject); because we think that the to-be-discouraged case (grouping metadata) would mostly rely on that position. To clarify, the discussion is about the use of nested triple terms to group metadata. The subject position restriction makes that particular way of grouping metadata more of a hassle. It would still be perfectly possible to use nested triple terms in the object position to group metadata. It's just more of a hassle, since you need to use an inverse property. E.g. Instead of
IIUC, a reifier does not necessarily refer to an occurrence of a triple in some surface syntax; it is possible that the triple does not occur at all. It is my understanding that it is a mechanism to group metadata that follows a specific context - see my prior post. |
There I meant occurrences, not triple terms - sorry if that wasn't clear.
Nesting and an occurrence focused design are orthogonal aspects. Reifications can be used in subject and object position, and in both positions they can be nested. Triple terms can only be used in object position, but IIUC they can be nested too.
What you are doing is essentially to construct a singleton type, a type that is so specific that it exists only once. But what's the purpose, besides maybe following an E/R design pattern? You are trying to annotate a specific instance, not all instances of that type. You can do that perfectly well with the occurrence oriented design of reifiers. So, yes, you can shoot yourself in the foot if you absolutely insist. The way your example is modeled is exactly what we try to prevent (also see EDIT below). However, I still wouldn't want to disallow any property but
Right, but that is another aspect. To avoid that connotation I could also use the term reification, or token, or instance. It doesn't change the fact that even for non-occurring reifications the use cases are predominantly referring to instances, not to the type itself. [EDIT The latest stab at this is to declare the subject of such a triple a reifier: a hint that `[ rdf:value true ]` is now of type rdf:Reifier should warn users that they are doing something unrecommended] |
|
@rat10 I think we are on the same page (correct me if I'm wrong) - it is possible to use nested triple terms to group metadata, but there can be good reasons not to, and reifiers can be better choices in some cases.
Note that I can easily shoot myself in the foot with reifiers as well, e.g., when accidentally choosing an existing one. But, perhaps it's not quite as easy to blow your foot off with reifiers, that is true.
I suppose this is what is bugging me a bit. RDF is getting into the business of enforcing particular modeling patterns. But, at the same time, it is considered (by some) a sort of low-level assembly language for KR. There seems to be a contradiction here. Even when granting this "mandatory" design pattern; the way it is being enforced seems rather artificial, i.e., by disallowing triple terms in the subject position. |
I'd put it more cautiously as "there might be overlaps" ;-)
Well, IIUC correctly it's not even possible to have multiple metadata annotations on the same level of nesting in triple terms (*) - so the mechanism is really very impoverished and my lead to undesirable expressivity (see example above)
IMO that's almost all cases, as I repeatedly stressed.
That seems like a pretty contrived concern.
IMO it's not artificial at all, because it tries to enforce exactly one design pattern: using the type as a blueprint to define a token, and only use that token thereafter. How to enforce that design pattern is not trivial, and your example above shows that the mechanism can be misused if it is not enforced overly rigidly. But to frame the mechanism as a whole as "artificial" doesn't do it justice. To the contrary it is as focused as possible. And it doesn't only concern subject vs object position: it concerns the use of triple terms as blueprints to nothing but instantiating tokens from. All that said: I would find it easier to lift this restriction if the (*) Wait a moment, is that concern valid for the reified tokens as well? Oh well, that of course asks for graphs on the syntax level as well. There may be issues when going for graphs, but there sure are downsides to not doing so. |
Sorry - I have no idea what you mean here.
With triple terms not allowed as subjects, I cannot just write the following in core RDF: Instead, I need a reifier (that I will not use in any other way): But that is even beside the point. We are making the particular design choice for everyone.
If I choose human-readable reifiers: But, as I said,
Unsure why you are saying "if not enforced overly rigidly". The subject position restriction does not apply there at all.
Both could co-exist. But, only if ReificationProperty/TripleTermProperty instances are not the only allowed predicates for a triple term. Using an instance of this class would indicate a special relation between the subject and object; i.e., the subject can be used as a token for the object.
Again, no idea what you mean. |
|
I agree with @william-vw here that we are defining our restrictions here around a particular design pattern and the question keeps being: is the fact that we like people to use reifiers enough to restrict the syntax of RDF? I dislike the restriction, because I would like to be able to directly express if we decide to introduce such a class. Or maybe But I can already see how @rat10 will dislike my first example, because he will wonder whether something could/should be a triple term and a lie at the same time. I get the point and yet, we might want leave the freedom to the RDF users to declare things as they want. We cannot predict the use of these constructs and we can still provide guidance through the syntactic sugar. |
|
@doerthe What other use cases do you have besides expressing RDF meta information? |
|
I am not sure wether I would call my use case only meta information. I dislike that we cannot express things which naturally follow from our entailments. I think that is more than expressing meta information. In addition to that, all your use cases could also be expressed using a triple term in subject position. I can easily write |
But what be would those things that you'd like to entail, besides RDF meta information (which entailing that something is of type
I could say the same of your desire to have it in subject position. The choice of position is not really random (it follows the usual modelling pattern that the most important thing is in subject position, which according to the current design is the reifier itstelf,), but the main issue is that there is a restriction on one position, right? That however follows from the clear purpose of the mechanism. Likewise I'm not aware of any demands for a set of inverse properties w.r.t. the RDF 1.0/1 reification vocabulary.
Because that syntactic sugar only takes us so far. Two examples:
So clearly the syntactic sugar is quite limited.
Another perspective is that we are replacing the RDF standard reification quad with a more concise mechanism, the triple term. The only purpose of that term is to act as a blueprint to instantiate reifications. It's not meant to be used on its own, just as there never was a RDF reification mechanism for triple types. This was easy to enforce with the standard reification vocabulary: it's what it is defined to be. That the enforcement is not so easy to achieve with triple terms doesn't mean that we shouldn't try. Instead you say that that special mechanism should become fully part of standard RDF, and I disagree. I think it should remain special. This is not arbitrary but there is a necessity for that, namely to ensure that statements about statements follow a predictable and coherent model. The obvious other argument is: the kind of entailments that you seem to be interested in seem to include literals in subject position anyway, so why isn't it satisfactory to you to just use generalized RDF? And one more thing: |
|
[...]
See below. The result is that, as discussed above, those ER-style primary keys have a peculiar reliance on ordering that the original data doesn't have (as there is no order of triples in a graph).
Yes, and you shouldn't as you are talking about a specific token, the lie perpetrated by Doerthe, not the
That may well be the case, but it is a hint that you really aren't talking about something in general but about something very specific, i.e an instance. [...]
What makes you think that I'm arguing from a perspective where the subject position restriction does not apply? I'm arguing against your proposal, and not always within the confines of your example.
I made a mistake here: the other severe restriction of Turtle-star is that it provides no support for multi-statement triple terms and reifications, see below. [...]
That it is impossible to express this or this or this i.e. neither triple terms nor reified terms nor the annotation syntax provide support for multi value reifications. |
You are simply choosing which statements to reify; this has an impact on the meaning of what is being reified.
That is a very strange thing to say!
Assuming I understood you correctly - it is my understanding that the reifier (or token) is being used as a proxy for the triple term. Anything you say about the token, you are really saying about the triple term. Why else use reifiers? You do not mean to describe the blank node Even if I did mean to describe the blank node, any negation - which there isn't - would be a problem there as well. Calling something a token does not somehow allow negation in RDF. Finally, the example isn't about the
I have been quite careful from the beginning to not suggest this as a replacement of reifiers. There will be times that reifiers are more useful to represent a particular example. That said -
Or Depending on what you want to describe; whether
Here, you are using the reification syntax, which currently translates into reifiers. Assuming you meant the triple term syntax: We've already had the discussion about switching
Note that Assuming something like Then |
|
I am finding that the same argument comes up again and again (but not quite as explicitly as here). Namely, there is a strong preference towards this particular usage of triple terms -
And
(bold added for emphasis) I haven't heard a compelling argument against using triple terms differently; aside from stopping users, in some cases, from shooting themselves in the foot. If that is the singular reason, then we should be clear about it. The reason is that, IMO, there are drawbacks from the restriction, which I tried pointing out in my (and Doerthe's) prior posts. It reduces the expressivity of reification in core RDF; as in requiring more triples - each time to declare a reifier - to describe the same thing. There is no such thing as a free lunch.
Just because syntactic sugar cannot express what you want it to, does not take away the fact that syntactic sugar is specifically geared towards the preferred use case. (It's a different discussion if this sugar is so limited or misleading that people simply won't use it, which I don't think is the case.) |
That may well be, but it still limits the usefulness of triple terms for creating (surrogate) composite primary keys.
Well, calling it a :Lie is not much different from calling it false. We are pushing around examples, without establishing the context that a proper vocabulary would require. It is however easy to imagine a vocabulary that gives the term ex:Lie a proper semantics to the effect that it calls something false (in the Boolean sense of the word). I had discussions about the dangers of statement annotation with Pat Hayes on the semantic-web@w3.org mailing list a few years ago, and he was very vary of this issue.
I don't follow, but let's not get deeper into this right now. It was rather intended to be a remark on the side..
No, most definitely not. In short, a reification refers to an occurrence (no matter if it actually happened/occurred or not) of a statement as a token, not to the abstract type. This difference is really essential, and if you haven't understood that right, that might at least in part explain why we don't come to an agreement.
This example is syntactically broken. I'm not sure what you mean.
No, I didn't. I wanted to point out that annotations on a reification composed of multiple triples is not supported in any of the syntactic variants we have. One has to compose it "by hand", using the
Well, that was my point.
|
Not to belabour the point - since it is tangential to this discussion - but there is a huge difference. I can call anything just about anything using terms I make up; it has no impact whatsoever on the open world assumption. You cannot construct a vocabulary in OWL that will result in negation as failure, as OWL follows the open world assumption (often to my chagrin).
They are indeed seems to be a misunderstanding here. I didn't follow many of the discussions, so I am basing myself on existing documentation, meetings, and talks I've had since I've joined. IIRC, the standard reification assumed the reification describes an existing triple in some RDF document; a reification could be called an occurrence in that way. It is my understanding (disclaimer) that a reifier is associated with a triple term using the regular IEXT:
I don't recall saying that. The only point was that syntactic sugar already translates into reifiers, i.e., we're already trying to push people to use triple terms in the object position. This brings into question the need to further restrict triple terms to only the object position.
Then I don't understand the point you were trying to make. |
... where that RDF document (and so, that "existing" triple) might be unmaterialized, or at least external to the RDF graph under immediate consideration. In other words, standard reification does not depend on, and does not itself materialize, a triple comprised of the |
|
@TallTed I'm basing myself on the following paragraph:
It is true that the reification does not imply the statement:
|
See https://github.com/w3c/rdf-star-wg/wiki/RDF-star-%22liberal-baseline%22 |
Wiki page:
Notes from the Semantic Task Force meeting 2024‐09‐13
The wiki page will be revised based on any discussion on this issue.
Minutes:
https://www.w3.org/2024/09/13-rdf-star-minutes.html
The text was updated successfully, but these errors were encountered: