Meeting minutes
ora: To be named: triple term, triple occurrence, rdf:nameOf
gkellogg: and description of "triple occurrence" vs "triple term"
<tl> RDF spec uses "instance" and "token" to refer to reifications
enrico: "triple term" is just a "triple"
AndyS: occurrence -> usage of a triple
niklasl: rdf:Triple
… need to look at use case to see if it fits and is neutral enough
<pchampin> "triple proxy"?
niklasl: I am unclear about same bnode/uri for two triples and as a triple occurrence
<pchampin> << :e | :s1 :p1 :o1 >>. << :e | :s2 :p2 :o2 >>.
pchampin: I like "triple term"
… they are different role to triple as elements of a graph
… need a name that recognizes that role are differents
gkellogg: "triple" is a production in concrete syntaxes. Need a different name.
olaf: Support for "triple term" over "triple descriptor"
… recognize the two roles/concepts
pchampin: +1 to gregg about need a type for this. rdf:Triple - not "triple term"
… (type as in rdf:Class)
<niklasl> +1, the construct (the 3-tuple) is a triple term; I also agree that the type can be rdf:Triple
pchampin: which is why "name" in "nameOf" is a weak choice for me
gkellogg: "mention" used before
<niklasl> +100 to "the thing is not a name" (see also "Haddock's Eyes" in Through the Looking Glass :P )
ora: "stands for" ? Appeal to intuition of user
tl: have triple type terms and triple occurrence terms
gkellogg: those are not RDF terms
tl: We need consistent naming
… :nameOf -> :instanceOf or possibly :occurrenceOf
enrico: name of the triple occurrence and the predicate could be the same (similar)
… can have several names
niklasl: easier to look at use cases e.g. marriages have start, end relations
… naming the relation from (asserted) triple and the annotation
… most neutral would be rdf:triple predicate
… or rdf:useOf maybe
<pchampin> rdf:triple rdfs:range rdf:Triple . make sense :)
niklasl: some use case would be better with specific vocabulary e..g "description"
… with semantic restrictions for the UC
… several options
gkellogg: advocate "mention" - describes the "mention" = use of the triple in the graph
<pchampin> is the *2nd mariage* of Richard and Liz a "mention" of a triple?
gkellogg: cardinality of one - entailment may affect this
<niklasl> Its more of a qualification of. Or a reificiation... :P
ora: should be be connected to name choice for triple occurrence choice
tl: +1 to Ora
… the property should be abstract ("general"/ed)
enrico: reviewed philosophy books ... triple referent , triple occurrence are the truth maker.
ora: "referent" has RDF history via PICS.
enrico: "the wedding of L and R" -- statement : w1 is the referent of this statement
pchampin: often used to distinguish syntax and semantics
… between domain of language (symbols) and domain of discourse
… this might create wrong expections
… like rdf:Triple giving rdf:hasTriple
… too neutral is better
… RHS is a triple
… unclear whether should encourage multiple names but would work is rdf:hasTriple (not "the name")
<niklasl> +1 no domain (domain is just rdfs:Resource)
pchampin: very general then name for domain makes less sense
gkellogg: "occurrence" implies it is really in the graph
… but we want use for a thing not in the graph e.g. to deny it.
<Souri> +1 to avoiding "occurrence"
niklasl: examples ...
<niklasl> _:x a :Claim ; :source <some-news-article> ; rdfx:theTripleRelation <<( <elizabethtaylor> sdo:spouse <richardburton> )>> .
<niklasl> _:y a :Marriage ; rdfx:theTripleRelation <<( <elizabethtaylor> a :Wife )>> , <<( <richardburton> a :Husband )>> , <<( <elizabethtaylor> sdo:spouse <richardburton> )>> .
niklasl: "has triple" work, "referent" works
tl: asserted vs not asserted seems to make a difference
… "claim of" OK, "fact of " not OK
<niklasl> <thisgraph> { _:x a :Fact ; :assertedIn <thisgraph> {| :comment "obviously" |} ; rdfx:theTripleRelation <<( <elizabethtaylor> sdo:spouse <richardburton> )>> . }
<pchampin> << :e | :s :p :o >> a :Fact . # or :Claim
ora: unasserted now may become asserted
<niklasl> <thisgraph> { <elizabethtaylor> sdo:spouse <richardburton> . }
tl: maybe even be the author considers it asserted wven if not mentioned
<pchampin> { ?x a :Fact; ?x rdf:tripple ?t } => { ?x :factOf ?t }.
<niklasl> +1 to Andy, we're looking for one choice of name
andys: annotation is used for asserted+rest
enrico: (examples in zoom chat for formatting)
… we "refer" to the specific statement, event, triple
ora: makes sense
pchampin: to TL: specific property : at x:45 in IRC
… model in N3
… OWL?
… we can type them to give the subproperty they relate to
… (discussion of subproperty)
… to enrico - nice example - predicate "refersTo" can be modelled as ":w2 rdf:type :Situation" then general property
enrico: less than "type"
<Souri> rdf:tripleForm may be?
pchampin: prefer rdf:triple for the property as neutral + name agreement => RHS is a rdf:Triple. Hard to restrict LHS.
tl: we never known what an URI refers to.
gkellogg: warn against against names differing only by case.
<pchampin> good point
souri: the connection should be neutral
… maybe "e has form s p o"
… "e has triple form s p o"
<pchampin> do mariages have the form of a triple?? :->
niklasl: like "rdf:value" - not sure about that
… support "hasTriple"
… what about lists as terms in the future
<pchampin> tl, about the referent of IRIs: https://
enrico: in the discussion we didn't consider reification => "reifies"
<ora> STRAWPOLL: "hasTriple" or something else?
<ora> hasTriple
<pchampin> +1
<gkellogg> +0.7
<niklasl> +0.75
<enrico> + why not?
<tl> something else
<doerthe> +0
<olaf> +0
+1 - several suggtions so far are OK
<pfps> +0
<Souri> +1 to rdf:hasTriple (or rdf:hasTripleForm)
ora: working choice "rdf:hasTriple"
souri: same e have s1 p1 o1 and also s2 p2 o2
gkellogg: considering entailments this happens
niklasl: need multiple "occurences" - RHS cardinality of one - functional properties => different names for the same thing.
pchampin: function properties re in OWL
… so baked into RDF, that sneaks in owl:sameAs
pchampin: not a strong syntax constraint because
<pchampin> :e rdf:hasTriple <( :s :p "42"^^xsd:integer )>.
<pchampin> :e rdf:hasTriple <( :s :p "042"^^xsd:integer )>.
pchampin: ... syntactical different in RDF
<niklasl> +1 no there being many problems with cardinality constraints
tl: why would 'refersTo' not work?
… it is a pretty good description
<Souri> So, just to confirm, we are planning to allow: :e rdf:hasTriple <( :s1 :p1 :o1 )>, <( :s2 :p2 :o2 )> . Is that correct?
tl: even if "refers to" doesn't sound very familar to me, I like it
AndyS: regarding the cardinality, we can add it as an advice
… rather than baking it into RDF
<pchampin> "if you use the same name for different [occurrences], *all bets are off*"
enrico: the point is not the card.constraint
… we want a many-to-many relationship
… no equality in RDF apart from the equality regarding literals (their values)
… if triple terms are syntactical equal, they need to denote the same resource
<pchampin> for me, what enrico describes is referential transparency
enrico: triples that have the same denotation for the elements should ...
… the same for the datatype system
… if triple terms occur somewhere else, they become a mess because they produce equivalence all over the place
… long discussion we need to have
… option 3 should be discarded by Andy's original proposal
… which is equally expressive but avoids the equivalence-related issues
… The problem of unicity, cardinality etc is much more complex
… In RDF plain, the equaliyt of literals does not show up, it shows up only in SPARQL
… with triple terms, it shows up already in RDF
pchampin: enrico can you write down an example where the issue of equality occurs?
… maybe take this offline
<AndyS> << :e | :s :p :o >> :source <foo> . :e :seen "date" .
AndyS: problem we identified with putting named occurrence in the data model
<AndyS> << :e | :s :p :o >> :source <foo> . <<:e | :s :p :o >> :seen "date" .
AndyS: There may be two different (occurrence) terms referring to the same
<pchampin> or: :e :source <foo> . << :e | :s :p :o >> :seen "date" .
AndyS: Because there would be two different ways to refer to the named occurrence
… one by simply using :e
… the other one by using the occurrence term
… << :e | :s :p :o >>
… enrico, which original proposal do you mean?
enrico: the one in December
AndyS: Ah, that is an expansion which doesn't have this problem
… and in fact that is Option 3 in the table
ora: anything else to discuss?
pchampin: regarding hasTriple, which doesn't have a lot of support
<enrico> <( :s :p "42"^^xsd:integer )> :p :o . entails <( :s :p "o42"^^xsd:integer )> :p :o .
<tl> i prefer "refersTo" to "hasTriple"
pchampin: my advice is to consider whether the term that we choose for this predicate is to consider it for a marriage example
<niklasl> What's the common relationship between a Fact/Mention/Quote/Event/Marriage/Relationship and "its" triple(s)?
pchampin: Then, refersTo, mentions, etc. don't work
pchampin: hasTriple has the advantage of being neutral
tl: no really not
<Souri> rdf:refersTo conveys a sense of a uniqueness -- does not "allow" multiplicity
tl: because it has a very strong connotation to refer to the triple as a syntactic construct (vs what the triple is about)
<pchampin> tl, the thing on the RHS *is* a triple, isn't it?
AndyS: what should we bring back to the wider WG?
<tl> "refersTo" IMO works very well for all kinds of reference: the triple itself and what the triple is about
ora: We have identified things that need to be defined, and things that need to be renamed
… and we have some suggestions.
<Souri> I prefer rdf:has... than rdf:refersTo based on the fact that we are not constraining to cardinality of 1
ora: Naming is difficult. tl has a valid point.
… and we concluded that rdf:nameOf is not on the list
AndyS: I can write a very short summary for the mailing list
<pchampin> +1
<niklasl> +1
pchampin: We also need a name for the syntactic construct that enrico calls the "macro".
… i.e., the Turtle expression of the form << :s :p :o >>
… or of the form << :e | :s :p :o >>