Meeting minutes
Phase 1 deliverables
nicholascar: Core and SPARQL set up
Task force updates
<AndyS> Have the wide reviews across W3C started?
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.
… If anyone sees build errors, they should be taken seriously, details can be found in the Github job
… Nothing new on Core, fixed some namespace issues in SPARQL. PR is open.
nicholascar: Errors in CR SHACL Core, errors seem to persist
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.
… 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.
nicholascar: Profiling: Things to do under profiling: List existing profiles, create new profiles.
… A new section has been added in SHACL Profiling, with suggestions pertaining to packaging.
… Feedback is needed, we need to be realistic. How do we take pieces of different files and combine them?
… The other sections have been filled in. Check if you have time, but packaging is where we need feedback the most right now.
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.
… 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.
nicholascar: What proportion of the UI should count as an implementation of SHACL-UI? SHACL-UI shouldn't have to validate everything.
AndyS: Rules: discussion about applying rules in the Time ontology.
<nicholascar> My Tim Ontology fiddeling in Python RDFLib: https://
AndyS: 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.
elianaP: No update on SHACL compact syntax
Governance for PNG and SVG
<YoucTagh> w3c/
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.
nicholascar: Do we just make that decision?
AndyS: We have to recognize that various drawing tools have different lifespans.
<TallTed> +1 SVG as primary graphic format, for many reasons, not least being preference by i18n WG and related features
nicholascar: The output of whatever tool we use should be standard SVG.
HolgerK: Is this realistic? E.g. a UML meta-language file might use additional features.
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.
… PNG images in docs may not look nice depending on the scaling
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.
… 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.
nicholascar: How many images to we have that go UML->SVG? Is it just the class diagram in Core?
… 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.
caribou: We can have several formats, content negotiation can be arranged so the preferred files are served. Editors can decide about (multiple) file formats.
AndyS: When we publish, we point to the folder with all files. Maybe we need to be careful about where we place files.
nicholascar: Any objections to have SVG as the master format?
… No objection raised. Let
… Let's place the source files in another location, and metadata about the software/version used to produce them.
… Let's decide details and communicate them over mail.
SHACL packaging
nicholascar: Document has been shared.
<AndyS> https://
AndyS: Packaging is not mentioned in other sections.
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.
… No link between ontology object and individual pieces.
… We can't "remix" packages right now.
… Does it make sense to say: "I have an ontology that has these parts (by reference)?
AndyS: A simple way to do that would be to reference things in online files.
… Not many implementations of direct naming.
… 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.
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.
… More interested in linking shapes to the ontologies where they originate.
… 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.
AndyS: Abstraction of packaging can be realized in different ways.
nicholascar: Use of named graphs could conflict with grouping methods.
… If we use definitional and memberOf properties, we may not need named graphs.
AndyS: My understanding was that the packaging section would be non-normative.
nicholascar: People usually send files around. Does anyone use other ways of packaging shapes?
caribou: Would be good to define use cases for packaging first. The scope can be very wide and we need to be clear.
mgberg: Follow-up to Andy: Would a SHACL processor be expected to understand those membership/collection properties?
nicholascar: No impact on the SHACL "machinery".
bergos: Using Hydra(?), can have separate resources and redirections between them. I usually don't bundle shapes but it would be possible.
… It is possible to point to separate shapes or documents.
nicholascar: in some tools (EDG?), shapes have to be in a file/ontology to be recognized.
mgberg: I would also like to be able to group shapes. No standards for this yet.
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.
… 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.
… Keen to be more specific about motivation and use cases. PR will be improved.
… Anything else to discuss? [no]