Meeting minutes
previous call's minutes
https://
ora: any objection to approving the minutes?
… I did send regrets, and they are not reflected
ACTION: pchampin to add ora's and greg's regret and chair name in last calls minutes
<ghurlbot> Created action 12
<TallTed> `regrets+ username`
<ktk> TallTed: tnx
RESOLUTION: minutes approved, modulo the changes to be made by pchampin
use-cases
<TallTed> for future, `3. Agenda` should be changed to `3. Review Agenda` which will not confuse the bots
ktk: following last weeks discussions, we should collect use-cases more systematically
… I haven't progressed on my action to find reviewers
ora: we did collect use-cases in the CG, my group sent some
… can we recycle these?
ktk: I have seen use-cases in other specs, is there a standard way of doing that?
<pfps> use cases from the CG would be a good start, but they should be some way to mark some as not relevant
<AndyS> https://
gkellogg: respec has some support for documenting use-cases
… there are typically UCR (Use Cases and Requirements) documents in other groups
… do we want to publish such a document, or simply collect UCs in github?
… If we go for a document, we need more editors. We might want to go the simple way.
<pfps> sorry something appears to be wrong with my audio
<pfps> i see no need to publish a document as long as they are in something like a wiki
ora: we have collected use cases for our 1-graph project
… with a lightweight process
… I propose we use the github wiki to collect them,
<pfps> let's have only one way to create use cases
ora: also accepting them on the mailing list, with a volunteer to copy them to the wiki
<pfps> there should be at least a little pain to submit something
ktk: I can do this
<AndyS> +1 to one page until too big
<pfps> it would be a good idea to have a template for use cases
<AZ> +1 to one page
ktk: one wiki page per UC, or all in one page?
gkellogg: I suggest all in one page
… creating a new page can be challenging
TallTed: downside of github wiki: no way to get notified of changes
… this makes it challenging to keep up with
ktk: it is versionned as normal git files
ora: alternative is to use issues
… I suggest to start with a single wiki page, and escalate to more structured if necessary
ora: Since we already collected UCs in the CG, I propose we focus on difficult client cases.
enrico: I suggest to label these use-cases as 'semantic' or 'syntactic', because they are very different kinds of UC
<pfps> a use-case template could have a place for categorization
ora: I like the idea of labelling
gkellogg: fuzzy border between use-cases and best practices
… the "what's new in RDF 1.2" could be a good place to put some "best practices"
pchampin: just to be clear: the "occurrenceOf" example in the spec is just that, an example
… other examples provided in https://
ora: also good to "advertise" what the new RDF allows to do
enrico: maybe useful to start the 'semantic'/'syntactic' distinction from my email
… most examples I see in the discussion are syntactic, e.g. about the triple itself
… e.g. date of insertion
… semantic use-cases are about the meaning of the triple
… e.g. X marriedTo Y since a given date
… In the semantic case, the triple should also hold as a fact in the graph.
… Not necessarily in the syntactic case.
… They also behave in different ways.
… The syntactic UCs, triples using synonym terms are still different triples.
… This is what is in the CG report.
… This is different for semantic UCs.
ora: is this different from the quoted vs asserted distinction we have in the CG report?
enrico: still, the spec says that quoted triples with synonym terms are always different
<TallTed> these are the same words and points that have been uttered in the past 3 calls. again.
enrico: It would be really strange to have { << X :married Y >> :since DATE }, and not to have { X :married Y } asserted .
<TallTed> has the final report of the CG been read and digested?
<Zakim> AndyS, you wanted to ask how we capture this as part of a UC in a wiki.
pchampin: stating { << X :married Y >> :until DATE } is a case where the triple should not be asserted
… Transparency Enabling Propeties are a proposed solution to bridge the gap between opaque quoted triples and semantic use cases
Doerthe: we had huge discussions on the CG mailing list about referential opacity
<pfps> I'm interested in seeing an approach that can cover the semantic case from a start of the syntactic case
Doerthe: in the end, the rationale was that opacity does not prevent semantic UC
TallTed: we are repeating discussions that occurred in the CG and are captured in the CG report
… we have to start with the work we have already done
… if we find holes, we can fix them
… based on use-cases
<pfps> I don't think that the WG has to just build on the CG. However, WG members should have read and understood the CG documents.
enrico: I believe that the previous work misqualified some examples
… the marriage I am talking about did happen, this fact remains true, even if the marriage ended
… the presence of opacity is indicating a probable modal problem
TallTed: telling people that RDF-star invalidates the way the modelled things in RDF is a non-starter
ora: I share TallTed's frustration
… not the first time in the history of RDF
… I see that the single wiki page approach to UCs may not work, if we need to discuss about controversial UCs
… I concur that RDF-star should not invalidate existing RDF
… We should identify the "untouchable" things?
ktk: I would then propose that we try creating issues for UCs
… with labels to categorize them
<Zakim> gkellogg, you wanted to suggest we create a GitHub issue template
<Souri> Ted, Are you refrring to the use of rdfn:... in the RDFn example I sent earlier today? Please note that, if we do not require "statement about statement." RDFn does not need thosw placeholders at all. So, in that sense, it is fully backward compatible with RDF.
gkellogg: github allows to create issue templates
I think we were using templates for UC in the CG
… respec can populate openissues in documents as well;
… this could be a way to include those use-cases in a document
ktk: have done it already, this is easy
… we can discuss the structure on the mailing list
… people will have to remember to use the template
AndyS: the template can be retrofitted in existing issues
TallTed: it might be worth looking at "RDF classic" use-cases, to be sure we don't break them
<ktk> As an <actor> … WHO
<ktk> I want a <feature> … WHAT
<ktk> So that <benefit> … WHY
TallTed: this might be just reusing the test suite
ktk: above is the UC template used by the CG; are we ok to start with this?
ora: it is a good starting point
update on the state of the specifications
<AndyS> https://
AndyS: I put the sparql documents in the repository
… gkellogg did a lot of work on the RDF ones
… put a list of all specs in rdf-new (link above)
… Now the documents need to be checked.
gkellogg: much more work on the SPARQL ones, because they were not based on Respec in the first place
… but they are soon editable so that we can make contributions
… I didn't want to edit documents until will sort out editors' responsibility
ora: we will seek editors,
… then maybe gkellogg can give a quick introduction to editing
gkellogg: a couple of us are having an informal call tomorrow
… no need to waste WG time for "mechanical" details
… I can describe my own practice
… Re Test Suite, they are currently currated by a dedicated CG
https://
… do we want to move them into this WG?
AOB
<pfps> presumaby a place for people to volunteer to be editors will be up soon
https://
pchampin: I created the GH project and linked all our repos to it
gkellogg: it would be nice to have a list of repos, that we can filter issues on
ktk: the issue template is now created
ora: this is the end, see you next week
<ora> Thanks pchampin for scribing
ktk: won't be here next week, will be on a plane