11:57:46 <RRSAgent> RRSAgent has joined #data-shapes
11:57:51 <RRSAgent> logging to https://www.w3.org/2025/10/20-data-shapes-irc
11:58:01 <AndyS> zakim, this Data Shapes WG
11:58:01 <Zakim> I don't understand 'this Data Shapes WG', AndyS
11:58:08 <TallTed> TallTed has joined #data-shapes
11:58:12 <HolgerK> HolgerK has joined #data-shapes
11:58:16 <AndyS> meeting: Data Shapes WG
11:59:22 <nicholascar> nicholascar has joined #data-shapes
11:59:34 <AndyS> agenda: https://github.com/w3c/data-shapes/blob/agenda/admin/agenda-2025-10-20.md
11:59:36 <agendabot> clear agenda
11:59:36 <agendabot> agenda+ Discussion
11:59:36 <agendabot> agenda+ Process
11:59:39 <nicholascar> present+
12:00:40 <HolgerK> present+
12:01:11 <DavidHabgood> DavidHabgood has joined #data-shapes
12:01:26 <simonstey> simonstey has joined #data-shapes
12:01:26 <elianaP> elianaP has joined #data-shapes
12:01:43 <ieben> ieben has joined #data-shapes
12:02:06 <bergos> bergos has joined #data-shapes
12:02:10 <TallTed> present+
12:02:26 <bergos> present+
12:02:28 <DavidHabgood> present+
12:02:34 <elianaP> present+
12:02:35 <AndyS> present+
12:02:38 <SimonW> SimonW has joined #data-shapes
12:02:42 <elianaP> agenda: https://github.com/w3c/data-shapes/blob/agenda/admin/agenda-2025-10-20.md
12:02:42 <agendabot> clear agenda
12:02:42 <agendabot> agenda+ Discussion
12:02:42 <agendabot> agenda+ Process
12:03:07 <elianaP> chair: Nick
12:03:13 <elianaP> scribe: Eliana
12:03:21 <elianaP> topic: Phase 1 deliverables
12:03:23 <mgberg> mgberg has joined #data-shapes
12:03:25 <SimonW> present+
12:03:30 <mgberg> present+
12:03:33 <ieben> ieben has joined #data-shapes
12:03:47 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/20-data-shapes-minutes.html TallTed
12:03:54 <ieben> present+
12:03:54 <elianaP> Nick: Core and SPARQL set up
12:04:00 <elianaP> Topic: Task force updates
12:04:12 <TallTed> previous meeting: https://www.w3.org/2025/10/13-data-shapes-minutes.html
12:04:14 <TallTed> next meeting: https://www.w3.org/2025/10/27-data-shapes-minutes.html
12:04:14 <AndyS> Have the wide reviews across W3C started?
12:04:17 <Robert> Robert has joined #data-shapes
12:04:22 <Robert> present+
12:04:29 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/20-data-shapes-minutes.html TallTed
12:05:35 <elianaP> HolgerK: Last week we found the cause of a build issue (HTML errors were flagged) blocking the auto-publication pipeline, so the draft is not updated. An update has been made.
12:05:49 <AndyS> q+
12:06:03 <elianaP> ...If anyone sees build errors, they should be taken seriously, details can be found in the Github job
12:06:41 <elianaP> ...Nothing new on Core, fixed some namespace issues in SPARQL. PR is open.
12:07:00 <caribou> present+
12:07:14 <AndyS> q-
12:07:17 <elianaP> nicholascar: Errors in CR SHACL Core, errors seem to persist
12:08:00 <YoucTagh> YoucTagh has joined #data-shapes
12:08:05 <YoucTagh> present+
12:08:38 <elianaP> HolgerK: Node expression document: PR for new feature encouraged by Andy, temporary name is nodes-where, it returns the nodes that conform to a given shape.
12:10:17 <elianaP> ...The feature is more flexible than a class. The algorithm may be slow depending on the implementation, as naively you could iterate over all nodes to check if they conform.
12:10:23 <elianaP> q?
12:11:16 <elianaP> nicholascar: Profiling: Things to do under profiling: List existing profiles, create new profiles.
12:11:18 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/20-data-shapes-minutes.html TallTed
12:11:45 <ieben> ieben has joined #data-shapes
12:11:59 <elianaP> ...A new section has been added in SHACL Profiling, with suggestions pertaining to packaging.
12:12:56 <elianaP> ...Feedback is needed, we need to be realistic. How do we take pieces of different files and combine them?
12:13:42 <TallTed> present+ caribou, danielbeeke, edmond, YoucTagh
12:13:49 <elianaP> ...The other sections have been filled in. Check if you have time, but packaging is where we need feedback the most right now.
12:14:31 <TallTed> chair: nicholascar
12:14:31 <TallTed> scribe: elianaP
12:14:40 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/20-data-shapes-minutes.html TallTed
12:14:53 <elianaP> edmond: UI: Still refining concepts (label resolution, shapes matching, do we call it a UI "processor" or  "renderer"?). List of definitions in a Github issue would be good.
12:15:42 <TallTed> s/scribe: Eliana/scribe: elianaP
12:15:53 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/20-data-shapes-minutes.html TallTed
12:16:38 <elianaP> ...VocEdit implementation built on top SHACL UI. Additional application layer to work with SKOS vocabs. Another extension where Github APIs are also integrated, supporting ttl files. Hoping to use that as a use case in the TF.
12:18:13 <elianaP> nicholascar: What proportion of the UI should count as an implementation of SHACL-UI? SHACL-UI shouldn't have to validate everything.
12:18:59 <elianaP> AndyS: Rules: discussion about applying rules in the Time ontology.
12:19:52 <nicholascar> My Tim Ontology fiddeling in Python RDFLib: https://pypi.org/project/timefuncs/
12:20:08 <elianaP> ...SHACL rules "touching" shapes unclear. What if there are other shapes that relate to the input of a specific rule, what is the "range" of it? What are the related use cases? Does anyone have examples of repeated applications of SHACL AF-style rules across different shapes? Would be helpful.
12:20:27 <edmond> edmond has joined #data-shapes
12:20:36 <edmond> present+
12:21:34 <elianaP> elianaP: No update on SHACL compact syntax
12:22:03 <elianaP> topic: Governance for PNG and SVG
12:22:19 <YoucTagh> https://github.com/w3c/data-shapes/pull/483
12:23:17 <elianaP> AndyS: We need to be make an explicit decision about PNG/SVG. Long-term assets would be good to have in SVG. Let's use SVG as the primary format.
12:23:59 <elianaP> nicholascar: Do we just make that decision?
12:24:57 <elianaP> AndyS: We have to recognize that various drawing tools have different lifespans.
12:24:57 <TallTed> +1 SVG as primary graphic format, for many reasons, not least being preference by i18n WG and related features
12:25:24 <elianaP> nicholascar: The output of whatever tool we use should be standard SVG.
12:26:01 <TallTed> q+
12:26:18 <elianaP> HolgerK: Is this realistic? E.g. a UML meta-language file might use additional features.
12:27:20 <elianaP> AndyS: Should be able to do easy tasks like fixing a typo in the SVG file. We don't have complicated diagrams at the moment.
12:28:20 <elianaP> ...PNG images in docs may not look nice depending on the scaling
12:29:38 <elianaP> TallTed: SVG are better suited for multiple viewports.I have edited SVGs made by other people, it is much easier to do by editing the text of the file. SVG editors have been improving.
12:30:48 <elianaP> ...Part of the userbase would like certain features and that moves development of these editors forward. Let's choose a format and push developers for the support we need.
12:31:17 <elianaP> nicholascar: How many images to we have that go UML->SVG? Is it just the class diagram in Core?
12:31:42 <caribou> q+
12:31:45 <TallTed> s/viewports.I have/viewports. I have/
12:31:48 <TallTed> ack me
12:31:57 <AndyS> q+
12:32:48 <elianaP> ...Let's have all images as SVGs, and if there is another source file that should be included too. W3C people would only need the final files, but we can keep the original files too.
12:32:55 <nicholascar> ack caribou
12:33:42 <elianaP> caribou: We can have several formats, content negotiation can be arranged so the preferred files are served. Editors can decide about (multiple) file formats.
12:33:43 <AndyS> ack me
12:33:44 <nicholascar> ack AndyS
12:33:53 <nicholascar> q?
12:34:29 <elianaP> AndyS: When we publish, we point to the folder with all files. Maybe we need to be careful about where we place files.
12:34:56 <elianaP> nicholascar: Any objections to have SVG as the master format?
12:35:26 <elianaP> ...No objection raised. Let
12:35:56 <elianaP> ...Let's place the source files in another location, and metadata about the software/version used to produce them.
12:36:23 <nicholascar> q?
12:36:33 <elianaP> ...Let's decide details and communicate them over mail.
12:36:43 <elianaP> Topic: SHACL packaging
12:37:23 <elianaP> nicholascar: Document has been shared.
12:37:35 <AndyS> https://raw.githack.com/w3c/data-shapes/shacl-packaging/shacl12-profiling/index.html#packaging
12:38:10 <elianaP> AndyS: Packaging is not mentioned in other sections.
12:38:41 <elianaP> nicholascar: We need to be able to say that an identifiable chunk of SHACL, and the pieces in the chunk can be reachable from the outside.
12:39:01 <elianaP> ...No link between ontology object and individual pieces.
12:39:31 <elianaP> ...We can't "remix" packages right now.
12:40:00 <elianaP> ...Does it make sense to say: "I have an ontology that has these parts (by reference)?
12:40:43 <elianaP> AndyS: A simple way to do that would be to reference things in online files.
12:40:52 <elianaP> ...Not many implementations of direct naming.
12:41:43 <elianaP> ...The idea was that the default graph is the "manifest" and is referring to other graphs. Named graphs aren't dereferenceable the same way online.
12:42:56 <elianaP> nicholascar: If we get many files with ontologies in them, they are manageable as such. But if we import them into a triple store, we need a way to keep the shapes in them organized.
12:43:28 <elianaP> ...More interested in linking shapes to the ontologies where they originate.
12:45:23 <elianaP> ...Other projects use inScheme. We could use isDefinedBy. Would like to have a set of shapes be identifiable. Therefore the suggestion to also use memberOf.
12:46:29 <elianaP> AndyS: Abstraction of packaging can be realized in different ways.
12:47:10 <elianaP> nicholascar: Use of named graphs could conflict with grouping methods.
12:47:31 <elianaP> ...If we use definitional and memberOf properties, we may not need named graphs.
12:48:04 <elianaP> AndyS: My understanding was that the document would be non-normative.
12:48:15 <caribou> q+
12:48:28 <elianaP> nicholascar: People usually send files around. Does anyone use other ways of packaging shapes?
12:48:34 <AndyS> s/document/packaging section/
12:49:10 <nicholascar> ack caribou
12:49:35 <elianaP> caribou: Would be good to define use cases for packaging first. The scope can be very wide and we need to be clear.
12:49:50 <mgberg> q+
12:50:07 <nicholascar> ack mgberg
12:50:47 <elianaP> mgberg: Follow-up to Andy: Would a SHACL processor be expected to understand those membership/collection properties?
12:51:16 <elianaP> nicholascar: No impact on the SHACL "machinery".
12:53:01 <elianaP> bergos: Using Hydra(?), can have separate resources and redirections between them. I usually don't bundle shapes but it would be possible.
12:54:12 <elianaP> ...It is possible to point to separate shapes or documents.
12:55:18 <elianaP> nicholascar: in some tools (EDG?), shapes have to be in a file/ontology to be recognized.
12:55:30 <mgberg> +q
12:55:41 <nicholascar> q?
12:55:47 <nicholascar> ack mgberg
12:56:04 <elianaP> mgberg: I would also like to be able to group shapes. No standards for this yet.
12:57:29 <elianaP> nicholascar: If we don't standardize this, people will use different methods for the same purpose, leading to low reuse. If we move forward with a specific packaging recommendation, it would be helpful to the community.
13:00:40 <elianaP> ...This, and metadata for shapes, would be highly useful for keeping track of and organizing large collections of shapes. Need a way to express hierarchies for shapes.
13:01:12 <elianaP> ...Keen to be more specific about motivation and use cases. PR will be improved.
13:01:34 <elianaP> ...Anything else to discuss? [no]
13:02:05 <caribou> RRSAgent, make minutes
13:02:06 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/20-data-shapes-minutes.html caribou
13:02:12 <elianaP> Meeting: Data Shapes WG
13:04:48 <TallTed> s/Nick:/nicholascar:/
13:04:57 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/20-data-shapes-minutes.html TallTed