Meeting minutes
W3C Breakout Day Participation 1
ora: a fully-virtual TPAC Breakout day is coming. Registration deadline is very soon. Do we want to present anything?
… I probably don't have time to prepare something. Does anyone else?
ktk: There are a couple of session types/lengths (50 minute and 10 minute), much shorter than at TPAC, purely virtual
ora: Anyone have interest in participating?
AndyS: I do. It's helpful to share work as we go.
[ chatter about possible time slots ]
ora: Can participate, but probably not build a presentation
niklasl: Can probably do some advance work, and join for the session
ora: We can follow up via the mailing list. Wanted to announce now to enable some time for advance work.
TallTed: Later is usually better for me, but will try to join whenever it happens.
Naming Things
<gkellogg> As it happens, I'll need to miss the Breakouts Day entirely.
ora: Enrico's email is as good a starting point as any...https://
<TallTed> s/any... https/
<TallTed> s|s/any... https/|s/any...https/any... https/|
gkellogg: thinks we need to name `claim` and `mention`
tl: adds `type` and `instance`
ora: you mean `triple type` and `triple instance`
pchampin: `claim` seems a misnomer. A triple that is not asserted is not a claim. Could live with `mention`.
… unless we want to repurpose `rdf:type` for `nameOf` or `instanceType`, we might need to think further...
enrico: `type` is very dangerous to re-use because it already has specific meanings in RDF and in OWL
ora: Is there some term in the same neighborhood as `type` and `class` that hasn't been taken yet, that we might be able to use?
<niklasl> "abstraction" and "reification"; but .... :(
ora: Could our explanations be improved if we say that our things are *like* `type` or `class`?
tl: We could just drop `type`, and talk about a `triple` and `instances of that triple`
pchampin: I see an elephant in the room. What about having one term being the name of multiple triples? Do we want to make that ill formed?
… Maybe it's a bad idea to have one name for multiple triples ... but maybe it's not?
… There are a lot of underlying assumptions behind our proposed names.
niklasl: The "abstract triple" vs "has triple relationship" ... As enrico noted, we need to also track `domain` and `range` of these things we're naming
gkellogg: Multiplicity problem is just a consequence of the model. We can't entirely predict or force usage patterns that emerge based on what we specify.
… What we're creating is kind of a parallel to named graphs, meant to be atomic graphs (containing a single triple), but these might contain more than one triple, which might have good reason...
… Complications of multiplicity might mean we need a(nother) different concept.
ora: We might need some "neutral" terms that don't convey to much meaning within their names
niklasl: We probably will need to explain the relationships between what we're specifying and traditional reification and named graphs...
… `claim` will be a thing I want to talk about. `rdf:value` might be an actual relationship I want to use; have been toying with it.
<pchampin> claims *can* be modelled by the << ... >> construct: ; but that construct will also be used for *other* things than claims
niklasl: `structured literals` and their values may play into this as well
ora: what does current RDF say about `value`?
niklasl: idiomatic property. its `domain` and `range` are both `resource`
gkellogg: we could certainly mint a subproperty of rdf:value
tl: I would be against it because we're talking about a small subset.
Souri: Agree with tl. We're building on RDF 1.1. Should avoid possible confusion-causing names.
… Associating multiple triple terms with a single name could have value, but once that's done, you don't have a way to describe *one* of those triple terms
ora: RDF 1.1 punted on some things that we're now running into and may need to specify more clearly
pchampin: I don't like `nameOf` for many-to-many relations. it makes the name less useful as an identifier. mixes the semantic and the syntactic levels
TallTed: welcome back, HTTP Range 14
niklasl: We'll need to see how our actual use cases are handled by each of these options
… `rdf:value` should probably be set aside. The discussion was worthwhile.
<pchampin> "proxy", "surrogate" ?
AndyS: difficulty is that relationship between subject and object is not singular, there's a two-step involved. I remember discussion of `rdf:namedOccurrence` that got shortened to `rdf:nameOf`
<Souri> +1 to rdf:proxy
<niklasl> I think Andy's right. In some cases we kind of pass from the "occurrence" "through the triple token" to the triple...
tl: `type` is used for lots of things already, so people are used to disambiguating it, so we shouldn't discard it yet
ora: we have lots of ideas, without any clear direction
gkellogg: rdf:proxy seems to have possibility
tl: but proxy "stands in" for something, which is not what we're doing
<niklasl> +0.75 for rdf:represents ...
<niklasl> ... or representedBy ...
enrico: most neutral term may be `associatedTo` or `relatesTo`
niklasl: `descriptor`? Makes sense to have range = triple, which seems to be what we want.
<pchampin> I can live with 'descriptor'
ora: What about acknowledging that what we're really after is the one level of indirection, and somehow reflecting that in the name
<Souri> rdf:refers or rdf:refFor?
<tl> "associatedTo" or "relatedTo" is so general that it's almost meaningless
[ ora & AndyS suggest that `nameOf` might be least-bad option ]
<niklasl> I'm still not sold on nameOf (does not really work for domain Resource and range Triple)
enrico: `isDenotedBy` comes to mind ... but may not be best in this arena
<tl> "nameOf" doesn't make sense. "e1" is the "nameOf" "e1". the relation between "e1" and teh abstract triple is different from naming.
<AndyS> denotes -> "to be a mark or sign of;"
enrico: `denotes` to me means there is an abstract thing, which we're calling tripleTerm. Occurrence is a denotation of that tripleTerm.
<AndyS> looking the word up ... "to be a name or designation for; mean."
<niklasl> <marriage> ?hastriplerelation <<(<elisabeth> :marriedTo <richard>)>> .
enrico: maybe `aNameOf`?
pchampin: `standsFor` might be usable in this context
tl: `instanceOf` seems self-evident option
<Souri> rdf:aNameOf sounds good, but we can avoid "name" by using rdf:aRefTo
<doerthe> sorry, I was distracted
<doerthe> I can take over ted
<ktk> tnx TallTed
niklasl: I would like to have the name neutral and technical, but the range should be triple
<AndyS> :e rdf:forTriple <<( :s :p :o )>>
pchampin: maybe instance of triple, to not have confusion to rdf:type, luckily, we will not have to write it too often
… but I am still worried about the many-to -many relationship
Souri: I agree with PA, that instanceOf might bring problems with the many-to-manyaspect, maybe "aName" would work, or better "aRefTo", for reference to
ora: we have many proposals, we should take into account the whole context, that is we should consider the names together
niklas: occurrence could claim things we would want to have as a type. Maybe we need to look at the names. A bad choice would be reification, maybe descriptor is a good choice? Maybe edge?Domain would be resource, range triple
<tl> maybe "edgeOf" A) can't be confused with types/instances in the general sense B) emphasized that the domain has an identity of its own and isn't just an attribute of the range
enrico: We should not give a name to the domain of the predicate, since that is really open how you use it
… could be an event, or an actual triple, a statement,...
… the range should be fixed.
<niklasl> <written-statement-token> rdf:descriptor <<(<s> <p> <o>)>> . <first-marriage> rdf:descriptor <<(<s> :marriedTo <o>)>> .
ora: we will need to talk about things, then we need a name
pchampin: I agree with Enrico, I like "forTriple" as it was also proposed by Andy
<eBremer> "aliasOf"
pchampin: the domain should not be fixed as it will be used in different ways
ora: should we take a strawpoll to see which terms are popular?
… we have to choose the names for all concepts together. I like "nameOf" but I am afraid that we will not find proper terms for the other concepts which fit
<niklasl> +1 for rdf:reifies (I think it's just as good as rdf:descriptor)
<pfps> I like xyzzy :-)
ora: occurrence is not horrible, but also not perfect
tl: nameOf and occurrenceOf are really different
<Souri> rdf:edgeFor, rdf:hasEdgeFor
<tl> edgeOf
<tl> edgeInstanceOf
<AndyS> My pref is not fixed but at the moment rdf:forTriple, rdf:reifies, rdf:tokenOf -- none perfect
Souri: I like edge, edgeFor, because we have edges on domain side. Edge is not taken and an edge for a triple is not taken yet
enrico: I like the edge idea
gkellogg: "remark"?
<Souri> rdf:hasEdgeFor
<niklasl> "an edge is an unordered pair {v,w}, while a directed edge is called an arc ..."
<AZ> My support for any name for this thing is irrelevant because I am in favour of "option 1" where this thing does not exist
pchampin: I dislike remark, the edge has the problem that it focusses on syntax and does not solve the many-to-many problem, but it has the advantage that it helps when connecting to property graphs
<Souri> +1 to a name based on "edge"
pchampin: we will not find a term which is generic enough to cover all possible future use cases will be impossible
<pchampin> well, properties are initially unary predicates, so let's no brag about people getting the terminology wrong :->
AndyS: In labeled property graphs they use edge for unordered pair or nodes, there the term is already taken
… tokenOf could be a proposal
… betoken also exists
<pchampin> we can indeed bite the bullet, the story would be "don't fear reification anymore, we just fixed it" :)
tl: RDF spec has token and instance when talking about reification, but the token is actually used differently, I like "reifies", because it does not say anything about whether it is asserted, no many-to-one problem,...
niklasl: reifies seems good to me
Souri: What is the domain of reifies? Also: I am worried about what users think here, the name is scary
… I am worried about that. Token is also very difficult
<tl> souri: what about edges reifying abstract triples, "edge" being the domain of "reifies"?
Souri: edge has the advantage that we can really connect to property graphs which is good for users. The terms are not identical, but users will get the connection
… it would really be good to help the many users of property graphs understanding RDF
<fsasaki> +1 to Souri about the value of the term "edge" for building bridges to the PG community.
Souri: Concrete suggestion: anEdgeOf, hasEdgeFor, something like that
AndyS
<eBremer> :e :means <<(:s :p :o)>>?
AndyS: None of the proposals work for me, reifies is very technical
… but maybe it works
<AZ> instead of naming the relation, use a blank node in predicate position :)
ora: Maybe it helps to also think about how we would explain the relation. People will not see the term we decide on that often, but we need to be able to explain the relation between triple terms and occurrences (current name)
… we can't use type, name, instance is also problematic...
<AndyS> Shortest -- "rdf:for" and rely on the spec text around it.
ora: I also agree with Enrico that we do not need a really specific name, we for example do not need a domain. We also need to be careful to not use terms with a fixed meaning in philosophy
<eBremer> +1 rdf:for
ora: where does it leave us? Maybe reifies is a good idea? Andys proposal "for" could also be good
… eBremer suggested rdf:means
<Souri> what would call the subjects of rdf:for?
gkellogg: rdf:means is appealing, but i could be confusing with semantics
… rdf:reifies might be scary, but it really says what it is, it is accurate
niklasl: I agree with that, also: people will most likely never use the predicate directly since it results from syntactic sugar.
<ktk> reificationFor
niklasl: I also thought about implies, but then we get into problems when we do reasoning
… many people also already encountered reification
<tl> mini-definition of reification: "reification is instantiation of triples. use the term 'reify' when you instantiate a triple"
pchampin: I also think that reification is accurate and we tried to not use the term, but we could say that we do "reification right"
<ktk> +1 on explaining multiple ways.
pchampin: of course we also need to have non-experts in mind, but we can use other predicates. I like the idea of "edge" to have good explanations
… for users we will have different stories
<Souri> +1 to rdf:reifies and explaining in multiple ways (edge, for example)
tl: to take the fear away, we should simply explain that this is what we do when we state the triple in that way, nothing more
<enrico> +1 for reifies
Souri: reifies captures what we are doing, important is that we can explain it well, but I think we could do that
ora: How is the subject of rdf:reifies then called?
gkellogg: Reification?
<pchampin> "new style reification" :)
<pfps> rdf:NSR
enrico: I agree, it would be reification
<niklasl> [] a ex:Edge ; rdf:reifies <<(<s> <p> <o>)>> . # ... etc. for all kinds of different types of subjects.
enrico: then the range could be triple terms
Souri: I was worried about the subject, I think I would see them as edge or sets of edges
<pchampin> +1 : rdf:Statement reification is just one kind of reification in RDF 1.1; Wikidata has its own form of reification, etc.
nicklasl: I wrote an example out. There are different possible kinds of reification and we now support many of them as opposed to classical rdf-reification
<Souri> A reification can be talked about as an edge or, in general, an edge-set.
tl: do we have many-to-many relation? is that possible? reifies would still work, but the domain is problematic, since that could be anything
<ora> STRAWPOLL: Could you support rdf:reifies?
<niklasl> +1
<gkellogg> +1
<tl> +1
<ora> +1
<pchampin> +1
<ktk> +1
<enrico> +1
<pfps> +1
<olaf> +1
<Dominik_T> +1
AndyS: the subject could be open, when talking about it, we will need to choose the word according to the context, of course we need to choose something in the spec, but that can vary
<TallTed> +1
+0
<eBremer> +1
<AZ> +0
<AndyS> +1 (not exclusively)
<gtw> +1
<Souri> +1 to reifies (and use "edge" or "edge-set" as one way of calling it in the spec)
<fsasaki> +0
ora: reifies seems to be the working candidate
… explanations can be crafted, we can use different subjects
ktk: The people who wanted to explain the idea in their context, could these please share that for example on the mailing list
<olaf> +1 to triple term
enrico: Is everybody happy with "triple term"?
<Souri> I am okay with triple-term
<pchampin> +1 to triple-term
gkellogg: I like that it is term as opposed to for example literals
<AndyS> +1 to triple term
<tl> +1 to triple term
pchampin: I think it would be important to write some kind of disclaimer about reification in our documents making the point that it differs from "classical" RDF reification and that reification is far more then this classical one
… we basically introduce a "new reification" and reification is used in many contexts
ora: Who takes care of the w3c breakout-day?
… I will
<niklasl> +1 these "occurrences" (statements, edges, graphs, claims, events, etc.) all reify triple terms.
<Souri> When is the W3C breakout day? (I joined late)
<TallTed> Souri -- Tuesday, 12 March 2024. see w3c/
<gtw> Can somebody link me to the use-cases document? I can't remember where they are, and didn't quickly find it looking at github.
<Souri> thanks
<TallTed> gtw -- https://
<niklasl> gtw -- I *think
<gtw> thanks, TallTed! Forgot that it wasn't named with "star"
<niklasl> I *think* https://
<niklasl> Note that this was before the syntax revision to macros for occurrences
<niklasl> (which we did because that works for use cases, which otherwise needed the sand-off relationship (now rdf:reifies) spelled out)
<niklasl> (*stand-off*)