See also: IRC log
<cygri> ack ??P17
<Arnaud> you can do queue= to clear the queue
<ericP> scribe: ericP
Arnaud: we've had several submissions to W3C
... also some proposals to the WG with various levels of support
... there are important issues which will consrain the solution
... but if you ignore those issues, there's actually a large core of agreement
... so we should let the differences push us into giving up on a common solution
... key question is "can you live with it?"
... proposals:
... .. LDOM proposal by Holger
<pfps> It would be nice to have pointers in the log
Arnaud: .. revised LDOM by ericP, which differs by seperating shapes from classes and sequesters templates into another spec
pfps: i submitted a response to the original LDOM proposal
Arnaud: i understood that to be a framework, vs. an alternative solution
<cygri> LDOM proposal (not sure if this is the right version): https://w3c.github.io/data-shapes/data-shapes-primer/
pfps: true, but it's really an attempt to not go the Lasagna Dumplings and Ostrich Meatballs route
... I interpreted the orig LDOM proposal: a philosophy and then SPARQL
... my approach is a completely different way to go
<cygri> LDOM as revised by ericP: https://w3c.github.io/data-shapes/data-shapes-primer/no-class-templates.html
Arnaud: not seeing how it's completely different. if we went by your proposal, what would we start with?
<cygri> pfps’ proposal: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jan/0119.html
pfps: one could complete that proposal by saying that shapes are exactly the same as in SPIN, i.e. fragments of SPARQL queries, and the rest of the proposal is a vocab consisting of three URLs for supplying scope for those shapes
... and validation is started with two arguments; voila the complete proposal
<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Feb/0184.html
Arnaud: we can go back to the high-level issues from peter's list
... q1: will we produce a modeling language?
... some people will say "it doesn't matter if you call it a modeling language."
... our charter isn't about modelling, but whether folks can use it for modeling is accidental
... if we'd claimed to work on a modeling language, W3C may or may not have approved the charter, and others folks would have joined
... the 'M' in LDOM was "Modelling"
<hknublau> The M stood for “Model” not “Modeling”.
ArthurRyman: i think it's wrong to try to ape OO programming in RDF
... it doesn't capture the totality of RDF
... you can serialize OO objects in RDF, but i don't want to exclude other uses of RDF
... i'd rather focus on graphs or datasets, describing it as a constraints language.
Arnaud: my assertion is that "no", we're not creating a modelling language
... works with the existing RDF stack (RDFS/OWL) and doesn't replace them
ArthurRyman: we should be complementary, filling gaps
cygri: pfps says the alternatives are "shapes language is designed to work with existing RDFS/OWL or replace them"
... it's a false dichotomy
... e.g. skos wasn't designed to replace RDFS
... things folks would have modelled poorly in RDFS class hierarchy can be modeled in SKOS
... we may indeed replace RDFS for uses for which RDFS was not well suited
pfps: i think that's a steep, slippery slope. we have to be careful and not supplant RDFS
<Dimitris> +q
Dimitris: one way is to translate from RDFS to shapes
... two ways to go from OWL/RDFS to shapes
... .. 1 use domain and range to generate shapes
... .. 2 use e.g. allValuesFrom in a closed-world interpretation
Arnaud: does that not antagonize pfps's concearns?
SimonSteyskal: [yes]
<cygri> Shapes allow doing things that people currently want to (but can’t) in RDFS and OWL. It’s inevitable that Shapes will compete with RDFS in some cases/
Arnaud: RDF graph? RDF graph plus RDFS? LD, where dereferencing is important?
hsolbrig: i have a narrow interpretation.
... the target data is triples.
... our solutions don't assign any special semantics of e.g. rdf:type; they're just triples
... i'm interested in a grammar or language that allows me assert what triples must be in a graph with no attention to the referents
pfps: in the vast majority of cases, type, subClassOf, are important to talk shapes
arthurryman: agree with hsolbrig; we should treat it like SPARQL
... sympathetic with pfps, but folks should apply the right entailment before validation.
... as a pipeline, first entailment, then validation
... in the linked data world, you have references, and you could model them as a set of graphs
... those referents could have a semantics of what you get from GET.
... but don't need to do that; just an input dataset and a shape, and we define evaluating the shape on the dataset
<iovka> completely agree with Arthur
<Zakim> ericP, you wanted to talk about SPARQL
<iovka> +q
ericP: treat validation as a black box. we can do any amount of inference before validation, potentially with multiple pipelines resulting in validating different closures.
cygri: in many discussions, we assume that validation that you do to an RDF graph
... arthurryman said it was something you do to a dataset (set of RDF graphs)
... i see why; it's a nice abstraction for dealing with LD and dereferencing, but we'd need a lot more specification to define validation over a dataset as opposed to an RDF graph
<Zakim> Dimitris, you wanted to talk about SPARQL and inference
Dimitris: we should use SPARQL semantics; in RDF unit, i do some lightweight RDFS inference to validate.
<Dimitris> ?s rdf:type/rdfs:subClassOf* <type>
ericP: so the inferential closure that's available to you is that which you can evaluate with SPARQL, including property paths.
... and no functional predicates?
Dimitris: right, only type inference
iovka: coming back to ericP's comment "we could have multiple inferences and validations", this should be defined externally.
... the scope should be defined externally, and then the shape is applied to the graph.
Arnaud: reacting to iovka, in the XML world, folks had different XML processing models in mind in XML Schema
... we provided no way to associate an instance with a schema.
... they got yelled at. i hope shapes can avoid getting yelled at
arthurryman: OSLC provides oslc:instanceShape to link a node to a shape
Arnaud: we talked about a requirement to associate a shape with a class
... wasn't controversial, but there was agreement that they should be linkable
... the next q is whether a shape is a class, which divides the group
... for some, a shape is not a class; don't conflate
... others say "if we make a shape a class, we can inherit rdf:type and rdfs:subClassOf"
... the mechanism are similar
<Zakim> cygri, you wanted to talk about R2RML
<hsolbrig> +q
cygri: IMO, i'd like to use shapes along side the modeling activities that i do with RDFS
... i'd like to constrain directly the RDFS classes
... i don't want to have a class hierarchy and a parellel shape hierarchy.
... R2RML (REC for mapping relational data to RDF) uses Turtle representation
<hsolbrig> -q
cygri: the entities we describe in R2RML are a database mapping
... these aren't RWOs which have an existence outside of the document.
... Data Cubes are statistical data that don't describe something in the real world
... it's nice to say that a Data Cube must have some properties.
<pfps> I don't see why this situation is not handled by associating classes with shapes, i.e., having shapes completely different from classes.
cygri: if we can't use classes as shapes, we end up making separate shapes, with a division between the modelling of shape and class
<Zakim> ericP, you wanted to talk about Record Classes
<kcoyle> eric: notion of record classes - classes are about things in the real world
<cygri> ericP article on record classes: http://www.w3.org/2015/02/shapes-article/
<kcoyle> ... record classes are graphs; thus "classShape" - which can be related to rdf class
<hsolbrig> +q
<kcoyle> ... identifier then is a class ... looks like owl punning. not clear what implications are where related class has relationships like subclass
<kcoyle> ... recordShape is a record class, not an rdfs:class
<kcoyle> ... example is in section 5 of of his LDOM spec
pfps: i think cygri is misidentifying shapes with ShExC shapes
... if ShExC shapes can say that fullfilment of a shape belongs to a class, we can address cygri's use case
ericP: so it's a method of recognition
<cygri> pfps, I’d still need to create a separate shape for each class
pfps: if we say that shapes can infer classes...
<cygri> pfps, meaning I still need to have both of these: r2rml:TermMap a rdfs:Class. r2rml:TermMapShape a shape:Shape.
<cygri> (pfps, I see what you mean that I may be able to get away without duplicating the *hierarchy* on the shapes side.)
<pfps> If shapes are classes then you should be able to say <node> rdf:type <shape>
<TallTed> pfps - yes! and I think you should.
<pfps> What does <node> rdf:type <shape> mean?
<cygri> (ericP, I find the “x classShape x” thing unacceptable. You and me understand it, but there is no way to explain that to normal people. It’s worse than having two separate resources. Punning would perhaps be fine.)
kcoyle: what if my node doesn't have a (useful) rdf:type or oslc:instanceShape arc?
arthurryman: in OSLC, we connect shapes to POST interfaces
<hsolbrig> +q
<SimonSteyskal> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jan/0119.html @tallted
<TallTed> tnx
pfps: so far, shapes have been satisfied by a node in a graph, not a graph
<hsolbrig> -q
Arnaud: here's what i hear:
... we have different major use cases:
... .. folks already using classes with constraints attached to the classes.
... .. folks not using classes or classes are conceptually different that there's no sense to mixing them
<hknublau> +1
<Zakim> ericP, you wanted to pitch record shapes again
<pfps> If shapes are classes then someone has to work out how that works out.
<cygri> right
<hknublau> Instead of ldom:classShape, we should use rdfs:subClassOf
Arnaud: let's have classes be different from shapes, but make it as easy as possible to assert that they are the same.
cygri: so that's fine, but if you want to find the easiest way to say that classes are shapes, you can use punning
... e.g. in OWL, you can use the same name for things that are things that are different in the metamodel
<hknublau> +q
<pfps> I would like to see a case where this dual hierarchy is needed.
hknublau: in the previous discussions, people think that we need an rdf:type arc. rdf:type is only one way to connect them.
... one of the opperations we support is to take any instance of a class and find the shape violations.
... another invocation is when it's triggered by rdf:type. that's a speciallization
... if we are defining shapes, and classes are already deployed, do we want to restart all that work and not interoperate with the work that's done
... for example, if we say that every class is also a shape, rdfs:subClassOf allows us to extend without a piece of code having to look for that and ldom:extends
... we can say that philosophically, shapes and classes are different. I fully agree.
... but keeping them separate will hamper adoption.
... proposal: folks who just work on ShExC could be convinced that they are macros
... we could define a shape that's a subclass of rdfs:Class (inherits the RDFS semantics)
<SimonSteyskal> owl nothing
<TallTed> noodling... <x> a <z> ; describedBy <c> .
<TallTed> <c> a Document ; hasShape <s> ?
<TallTed> <z> a nonDocument ; hasShape <s> ?
<TallTed> <x> a nonDocument ; hasShape <r> ?
hknublau: ldom:Shape would be a subclass of rdfs:Class and would have a special status like owl:Nothing, which has no instances
<hsolbrig> +q
<hsolbrig> -q
hknublau: could add a constraint that ldom:Shape can't have direct instances
<hsolbrig> +q
ArthurRyman: in a given document, the way you get to a node in a graph determines the constraints.
<hknublau> +q
ArthurRyman: when you get a license, you are a Person, and you have a bunch of properties
<cygri> ArthurRyman, you want to validate a DriversLicenseApplication, not a Person
ArthurRyman: the emergency contact is also a Person, but only with one a phone number
hsolbrig: hknublau said we'll have a special class called ldom:Shape that has no instances
... the semantics of rdf:type attach an instance to a class.
hknublau: if you have a different relationship, you don't have to use rdf:type.
... you could use oslc:instanceShape or something from outside control
... ArthurRyman's example is a use case for ldom:valueShape.
... global constraints on Person would only be e.g. every Person has a first name
... we have proposals for adding contexts for using a applying of constraints to data
... when we publish something, the default interpretation should be that all of the constraints attached to the classes can be applied, but we can override this.
Arnaud
<hknublau> I agree, for those who are not fond of compact syhtax, they can use ldom:Shape.
Arnaud: we can't have the syntax affect the model.
... if we want to combine things via punning, we may need extra arcs.
<TallTed> scribe:TallTed
Arnaud: seems clear that neither side is going to convince the other, so we probably need to accommodate both views
ericP: we say that Classes and Shapes are different, but make no rule against punning with them, and come up with some mechanics to make that work
<cygri> yes
ericP: something like OWL punning
<ericP> PROPOSED: shapes and classes are different but one can pun them by using the same node as the subject of e.g. rdfs:domain, range and oslc:predicate arcs.
<pfps> I would like to see some indication that punning produces some advantage over either of the other viewpoints.
ericP: how does pfps feel about Shapes being subclass of rdf:class?
hknublau: punning allows each side to acknowledge that they might be wrong, or not fully understanding the other approach, and able to pursue their approach...
<Dimitris> I made a page for this here https://www.w3.org/2014/data-shapes/wiki/Core_Shape_Definition maybe we add more options and vote
<hknublau> @cygri because you cannot then use rdfs:subClassOf between shapes.
pfps: OWL has punning, but that took a lot of technical details to make work
[ericP and pfps try to find a way to word a mutually acceptable proposal along the punning lines]
<hknublau> @cygri Yes, OO has "abstract" classes, and shapes are like abstract classes.
pfps: one IRI with two meanings leaves the system to figure out which meaning matters, so there must be a way to define that split
ericP: what if we split on ldom:property, which implications apply to shape, and everything else applies to class
pfps: I don't think it's good to relate shapes to one another via subClass, but others seem to disagree
... in rdfs it's not possible to make this split, because of the mantra of "say anything about anything"
<hknublau> +1 I asked for examples before.
<hknublau> Any Shapes example I have seen so far could have been modeled with classes.
pfps: someone on one side has to come up with examples which can't be morphed into the other side
hsolbrig: if you interpret rdf:type as instanceOf, and say that someone is a foaf:person, and and say further that foaf:person is both a shape and a class, then you get systems that say that someone cannot be both foaf:person and a set of triples
... deciding whether skos:concept was an OWL class or not was a challenge. decision was to not make any statement about relation between these, and let usage explore ...
... for example, we can say { Mary a foaf:person; instanceShape myPersonShape }. question is whether { Mary instanceShape myPersonShape } implies {Mary rdf:type foaf:person}
... I suggest we take no position on this
<hknublau> To me this just highlights the fact that it is unhelpful to have two parallel worlds.
<hsolbrig> PROPOSAL 1: there will be an instanceShape predicate asserts that the subject is associated with a shape. We will take no position on whether instanceShape is an equivalentProperty to rdf:type and will state that both the assertion and the absence the assertion are valid interpretations of the shape semantics.
<hsolbrig> PROPOSAL 2: there will be an classShape predicate asserts that the subject is associated with a shape. We will take no position on whether classShape is an equivalentProperty to rdfs:subClassOf and will state that both the assertion and the absence the assertion are valid interpretations of the shape semantics.
<cygri> hsolbrig, I want validation to be triggered by the presence of rdf:type. I think your proposal doesn't let me do that.
<cygri> hsolbrig, I want { X a MySubmissionRecord } to trigger constraints attached to MySubmissionRecord
<hknublau> The complications of :instanceShape and :classShape are exactly what I would like to avoid. I don't think we shuld include them in the standard.
<pfps> Complications of :instanceShape and :classShape over what?
<hknublau> @pfpf over just using rdf:type and rdfs:subClassOf
<Dimitris> Although I am on the class-based validation side I would prefer for shapes to refer to classes not be directly attached to them, my proposal would be the following: something like the following https://www.w3.org/2014/data-shapes/wiki/Core_Shape_Definition#Resource_Shapes_like_2
cygri: I think these proposals requires me to say that rdf:type means instanceShape applies. I don't want to have to say that.
ArthurRyman: the way some of our systems work, when you submit/POST a resource, the validation is triggered by and based on its rdf:type
... I suggest we just pick one and go with it, subject to revision if experience dictates
<hknublau> I am not OK with Eric's current revision. It includes ldom:nodeShape/classShape.
<ArthurRyman> why do you object?
ericP: some people seem to need clear differentiation between shapes and classes. others have classes and just want shapes to automatically apply there....
<hknublau> @TallTed I don't think (TopQuadrant) belongs up there.
cygri: punning moves the issue, but may not solve it
[ ericP and pfps try to find enough common ground for a Plan A to go forward ]
pfps: SPIN is an existence proof that Classes and Shapes can be considered entirely different. SPIN is roughly rdfs with the ability to associate classes with shapes.
... you don't get the issue of recursive shape recognition. a Shape in SPIN can't directly reference another Shape, it has to go through a Class.
ericP: I'm not sure that cygri's recordClass is going to be met by this
pfps: there's a lot of syntax sugar to make this work, but it *does* work
cygri: in the SPIN sugar layered atop SPARQL, you have to make the extra hop applying constraint to class...
... (a version of) LDOM adds more sugar to this, allowing attachment of constraints directly to URIs of existing classes, piggybacking on existing subClassOf hierarchies
pfps: RDF is odd because there's no macro.... you can't start with { <node> rdf:type <shape> } and have it be rewritten { <node> ldom:instanceshape <shape> }
... { <node> rdf:type <shape> } persists, and has implications thereafter
... ShExC might could be used to expand { <node> ShExC:blah <shape> } to { <node> rdf:type [[ [] ldom:instanceshape <shape> ]] }
Arnaud: clearly no easy path forward. question is, what hard path should we take?
pfps: SPIN should be able to handle all user stories/requirements, except those which require recursive shape recognition
[ pfps, ericP, Arnaud dive into SPIN details ]
pfps: spin:constraint maps to a container, which could be considered a shape, contains a property, which is a unicode representation of a SPAQRL query
... we need a benefit over SPIN, to do something new
ericP: does tractability, iovka's research, measure up here?
pfps: several sources of complexity in shape evaluation. especially but not limited to blank nodes, SPARQL constructs like OPTIONAL and path expressions...
[ discussion of SPARQL query optimizations ]
* break for lunch, return at quarter past the hour
<hsolbrig> scribe: hsolbrig
Arnaud: At the workshop we determined that we needed a declarative solution instead of SPARQL. SPIN does not fit the bill from that point of view
<hknublau> SPIN was not correctly represented at the workshop.
Arnaud: We need to return to the closest we've been to consensus, as captured in the revised LDOM proposal that Eric has started.
... Propose that we return to that and and examine it in the light of punning...
<hknublau> +q
<pfps> If you have classes, then there is no need to organize shapes. The shape organization can be parastic off the class organization. This is what is done in SPIN.
hknublau: Some of Eric's work is improvements, others are not. ldom:Shape and decoupling with rdf:type is ok. Issue with the 2 or 3 properties in ldom namespace -- ldom:extends in particular
... instead of assuming we need them, lets start where we are and add if we discover they are needed, add them then
... already have a mechanism for associating instances with shapes and cover all syntaxes
... prefer to put other properties in another namespace, but not in the standard
ericP: does this mean we have to use rdf:type and rdfs:subClassOf
hknublau: no. There should be an official way to say you want to use another property in the header. Default ("the standard") we should assume that rdf:type is used and override if no...
... ldom is defined as classes, which allows to validate ldom against itself. If we don't do it with type/subClassOf this would all go away...
... type/subClassOf should be the default but people can override locally.
Arnaud: If we started with Eric's LDOM, we will have something concrete that people can raise issues against.
hknublau: Are we talking the primer? Then we have problems because templates have been removed, and we've got extra properties. Why not start with primer + charter specification
Arnaud: All we have now are drafts of primers. There are no specifications yet. The key difference between revised proposal and original are that shapes are no longer just classes.
... Can we agree to keep them separate and then explore ways to put them together?
... Can we agree that shapes are not classes and we need to find a way to combine them?
hknublau: The problem is still that Eric's draft still includes ldom:extends. The real difference is in that triple
ericP: For people who want to have a shape that separates employee role / customer role, by default we are no longer to do this, as we are treating shapes as classes.
<pfps> I still don't see why it is problematic to say foaf:person spin:ask <shape>
ericP: There are a bunch of different issues with shapes vs classes. (lists some)
hknublau: What is you have data without any type arcs. How do you do this if shapes and classes are different things? You don't expect to see a statement in the data that asserts conformance.
... what mechanism to you propose to use in these examples?
ericP: there is no coorelation with them in classes. They have no behaviors attributed to conventional classes. There is no advantage and a lot of baggage
<pfps> The working group hasn't determined which valication mechanisms are going to be provided. Some mechanisms could provide direct control over what validations are performed, as in "validate ex:foo against ex:shape in ex:graph"
cygri: If you say x is class y without making any assertions about about y, there are no consequences
<hknublau> (cygri said the above)
oops
ericP: If I have a scenario where I'm reusing a class for multiple purpose, I wouldn't want to use that class for my shape, right?
<pfps> There is no reason that I can think of not to use multi-purpose classes to control shapes.
<hknublau> Classes can do everything that shapes can (and more). Is the "more" the issue?
cygri: you would essentially define subclasses of foaf:person for customer, etc.
<pfps> RDFS classes can do recognition??
<cygri> pfps, yes via rdfs:domain for example
ericP: we have a lot of use cases with no type arcs and some with multiple type arcs. The same instances will be tested as different shapes in different points its life cycle...
<pfps> I have a program that is supposed to prepare mailing lists. It depends on foaf:persons having names and addresses. The natural way to do this is to attach the shapes to foaf:person.
<hknublau> +q
ericP: I don't think that we have any coorelation between classes that appear in our instance data and the classes we want to attach our constraints to
<cygri> yes
ericP: shape classes are going to be in a different branch than foaf:person, businessdata, etc.
... what is the value of having them be clases? Just subClassOf, and, if so, why not other transitive propeties
hnkublau: the issue isn't how to link instances to shapes, it is only subClassOf. If we allow all these other properties, we end up with multiple representations and no re-use
<cygri> ericP, the value is: it makes record classes easy, and doesn't make other use cases harder.
<TallTed> more noodling...
<TallTed> Classes (rdf:type) have Instances, which have RDF Representations (records), which have Shapes.
<TallTed> Classes don't have Shapes, per se, though an application/context might restrict/require the Representations of Instances of that Class to certain Shapes.
<TallTed> Instances are of Types (which is to say, they are an Instance of a Class), declaration of which may be included in their RDF Representation.
<TallTed> Multiple Shapes of Representation might be relevant for the same Instance (and thus for the same Class/Type) in different contexts.
<TallTed> Some contexts might say that only one Shape is valid for that context (e.g., requiring a foaf:name for a foaf:person).
TallTed: They aren't saying the shape isn't applicable to foaf:Person, but to a sub class of person
... We keep forgetting which things are tangible and which are intangible
<pfps> You can validate a node in an RDF graph against a shape. Other stuff - instance, description, etc. - fit elsewhere.
<ArthurRyman> +1
<pfps> ... or maybe a node in an RDF graph in an RDF dataset.
Arnaud: There is too much focus on the type arc. There are different ways to associate an instance with a shape, it is the use of subClassOf
pfps: I believe that the original LDOM is a modeling language intended to supplant RDFS. The working group should not do this and it isn't in its charter.
Arnaud: It might be a side effect, but it wasn't the intent.
pfps: disagree. I think it is
TallTed: If RDFS satisfies, there is nothing to do. Else we need to do more and more features.
pfps: I think there was something seriously wrong with LDOM. Uses rdfs namespace with different semantics.
... If it was really the case that the output of this working group interfaces with RDF ontologies we've done a good thing, but I don't think that is where we are going
cygri: If we look at resource shapes, you can use them for things that are in rdfs territory, but there are rdfs misuses as well such as using domains and ranges to try to constrain when it doesn't have the desired effect
... Some rdfs uses would be better using spin/shex. There is some perception of perceived overlap, but not. What features of rdfs do you (pfps) see as replacing or competing with rdfs.
pfps: everything and nothing
... Some things would be better done in a frame system, but the working group hasn't been chartered to make a frame system.
... There is bad data out there that comes from people not understanding rdfs. If they realized what they should have been doing was constraints, the use of rdfs specific notions in ontologys may decrease, which is not a bad thing
<cygri> thanks pfps
<Arnaud> STRAWPOLL: a) start from LDOM proposal (i.e., shapes are classes), b) start from Revised LDOM proposal (i.e., shapes are NOT classes)
<ArthurRyman> b
<ArthurRyman> b:+1
<ArthurRyman> a:-1
<SimonSteyskal> a: +0
a:-1
<SimonSteyskal> b:+1
b: +1
<kcoyle> a:-1 b:+1
<hknublau> a+1 b-1
<labra> a:-1
<ericP> a:-1 b:+1
<labra> b:+1
<iovka> a-1
<pfps> The notions underlying the revised LDOM proosal are decent, but the primer still includes a lot of fluf.
<pfps> a: -1, b: 0
<ArthurRyman> a:-1 b:+1
<iovka> a-1 b+1
<TallTed> a:+0.5 b:+0.5
<Dimitris> a: -0.5 b: +0.5
<cygri> a: -0 b: -0
<cygri> would like more clarification on the fundamental questions first
<Arnaud> PROPOSED: start from Revised LDOM proposal (i.e., shapes are NOT classes)
<SimonSteyskal> +1
<kcoyle> +1
+1
<ArthurRyman> +1
<ericP> +1
<iovka> +1
<labra> +1
<TallTed> +0.5
<Dimitris> +0.5
<pfps> +0.5
<hknublau> -1
<Arnaud> PROPOSED: start from Revised LDOM proposal (i.e., shapes are NOT classes), and explore ways to combine shapes and classes such as punning
<TallTed> so... choices really were/are (1) shapes are classes (or perhaps, classes are shapes) Vs (2) shapes and classes have an indeterminate relationship
Arnaud: My understanding is that punning allows you to have a shape and a class without them being the same thing.
cygri: I don't think we need the "i.e.". We've made progress on the issues, but I'm not ready to make a decision on that particular question.
<Arnaud> PROPOSED: Start from Eric's Revised LDOM proposal, and explore ways to combine shapes and classes such as punning
<TallTed> +1
<ericP> +1
<cygri> +1
+1
<labra> +1
<SimonSteyskal> +1
<kcoyle> +1
<hknublau> +0.5
<Dimitris> +0.5
<pfps> +0.25
<iovka> +1
RESOLUTION: Start from Eric's Revised LDOM proposal, and explore ways to combine shapes and classes such as punning
<pfps> The revised LDOM proposal has roughly two parts - a simple shape language with an extension into SPARQL and a way of controlling validation. The shape language is sort of half way between SPIN and ShExC. The control is SPIN control plus some other stuff.
Arnaud: Given what we've just said, this is not a spec, it is a primer. What do we do next?
<hknublau> +q
Arnaud: There are three possible deliverables ?, the vocabulary, and the semantics associate with it.
hknublau: I have thought about how to formalize this. Templates that create a higher level vocabulary backed by something executable, SPARQL by default. Propose we keep it as that
... We could say that there are other executables like JavaScript w/ a triplestore API. LDOM:SPARQL is the name of the SPARQL vocabulary
<labra> +q
hknublau: Two documents will be hard to do because we will have to include examples of rich constraints. Should be self contained as it includes SPARQL queries. Too difficult, so propose we start with a single spec document
labra: We should concentrate of defining the language features independent of the syntax and implementation details.
... SPARQL templates are an implementation detail. Prefer very clean separation
<Zakim> ericP, you wanted to say i started on an abstract syntax
<ericP> gentle introduction
ericP: I started with an abstract syntax when I was working on the primer. I think that the "correct" stuff should go into a separate document (abstract syntax) and be separate from the primer
<Zakim> cygri, you wanted to mention SPARQL algebra
ericP: section 3 has examples that is meant to be moved from ehre.
<ArthurRyman> we can't hear richard
<TallTed> very garbled
<ArthurRyman> better now
cygri: murgle fug fub... nice clean formalism. SPARQL as a ... murv gieep ... surface syntax ...
<pfps> What part of the valildation can't be done in SPARQL?
ArthurRyman: To completely describe the validation we can't do it all in SPARQL. We need a real formal specification and a normative translation into SPARQL
<iovka> +1 to Arthur
ArthurRyam: We need a good test suite and I'm willing to work on the formal spec.
<ericP> <x> ldom:property [ ldom:valueShape <x> ] .
ArthurRyman: Would propose formal be in Z
<cygri> cygri: SPARQL algebra (plus a small extension) can serve as a real formal specification.
pfps: Recursive shapes can't be done in SPARQL, what else?
<hknublau> +q
<Dimitris> +q
<pfps> I'm not in favour of having the spec written in Z.
ArthurRyman: mathematical formalisms like cardinality expand quite a bit into SPARQL, but we need a translation written in SPARQL
<ericP> pfps, how about set builder notation?
<pfps> pointer to set builder notation?
hknublau: I am strongly against an abstract syntax. Only adding complexity
<ericP> I had claimed to have written down some AS at the beginning of ostrich meatballs section 3
hknublau: Do we really want to do that? It is totally redundant
+q
<labra> +q
pfps: We don't have a spec for ShEx in Z
<pfps> The definition of ShExC isn't in Z. It is in Z plus an escape into a recursion.
<ArthurRyman> Z can handle recursion
<cygri> What the hell is Z?
<ArthurRyman> a formal specification language
<TallTed> http://en.wikipedia.org/wiki/Z_notation
<ArthurRyman> there is a type-checker
<ArthurRyman> I used it in WSDL 2.0
<ArthurRyman> It can be embedded in HTML
<hknublau> I think this spec could be part of the ShExC-like write-up.
labra: One of the requirements is that we define a high level language, you need an abstract syntax.
<ArthurRyman> http://www.w3.org/TR/wsdl20/wsdl20-z.html
<labra> http://labra.github.io/Haws/ldom/index.html
labra: I've been working on an operational semantics as well.
Why use something (ASN.1) that actually works.
<Zakim> ericP, you wanted to propose n specs, one turns into a REC and n-1 turn into notes
Anyone can write anything, no?
+q
<hknublau> +q
<cygri> No, the fact that you've done the exercise does *not* mean it works.
<labra> +q
<pfps> +1 to cygri
<cygri> It doesn't save you from the hard thinking.
<ericP> cygri, pfps, how about "if you've done the formalism, you've caught some potential bugs"?
<pfps> Perhaps the main point of a formal spec is to make you do some hard thinking.
hknublau: The main deliverable is an RDF vocabulary and SPARQL. I think that Z introduces another step. The problem is already solved, we have the queries, the impleentation and it runs
<cygri> ericP, "…and perhaps introduced some new ones"
<ericP> cygri, interesting, is that a real liklihood?
labra: The formal specification helps to develop the test suite.
<hknublau> SPARQL does too.
<cygri> ericP, I don't know.
<ericP> cygri, btw, since you're phone is somewhat challenged, i can say for you "you don't actually need a machine testing, you just need to think hard"
<cygri> what is "the implementation"?
<hknublau> +q
ArthurRyman: there is a danger in Holgar being the author of the spec, as the formal spec and the implementation can get muddled
<pfps> If the meaning of shapes can be determined via a translation to SPARQL, then that should suffice as the semantics. However, SPARQL does not suffice for recursive shape recognition.
hknublau: Once we have "that algorithm" we give it a name and everything else is done.
<Zakim> cygri, you wanted to ask if there's any opposition to have a normative expression in SPARQL
<pfps> There can be multiple normative specifications.
<labra> why not a WG note?
<Arnaud> PROPOSED: Define semantics using SPARQL as much as possible
<Dimitris> +1
<hknublau> +1
<TallTed> +1
<cygri> +1
<ArthurRyman> +1
<labra> +0
<iovka> +0
<kcoyle> +1
-0
<ericP> +1
<pfps> +0 if SPARQL suffices for the semantics then it should be used, but it appears that SPARQL is not going to suffice
<hknublau> I am pretty sure that SPARQL with the extra function(s) is enough.
RESOLUTION: Define semantics using SPARQL as much as possible
<hknublau> And SPARQL can have extension functions - it is still SPARQL.
<pfps> Well, of course, SPARQL with extra functions would suffice.
<pfps> OK, then instead of SPARQL I should have said SPARQL without extension functions
I'm sure it is enough, but I'm concerned that SPARQL will be there reference for what an expression means
<hknublau> Harold, are you concerned that people will actually understand the semantics?
<ericP> now that i think i understand what "define semantics" means, i'd like to change my vote
<ericP> +0
<ArthurRyman> Zed
<ArthurRyman> yes
Arnaud: We can defer the final decisions to a "beauty contest" down the line
... Now that we've agreed to use the revised LDOM proposal, maybe a finished draft would be a good first deliverable, with lots of issues to show we don't agree on all of it
<pfps> I was just looking over the ShExC specification in Z. It appears to me that the spec fails on recursive shapes.
<pfps> FPWD of the primer in three weeks seems very optimistic.
Arnaud: Can we target a week to get a public working draft out in a week.
<ArthurRyman> I will look at the recursion issue.
<pfps> I like CONSTRAINTS
Is that an acronym?
<pfps> CONSTRAINTS = Class-based Or Neutral SpecificaTion of Rdf And lINked daTa Shapes
Arnaud: Who will write the specification in SPARQL?
<hknublau> I can do the SPARQL stuff.
<pfps> To turn the document into a Primer the current content needs to be removed and replaced by other content.
ericP: I like it when there are very precise definitions. I like being able to talk about a propertyshape without having to repeat myself.
<kcoyle> concepts? http://www.w3.org/TR/rdf11-concepts/
<cygri> we should have a name before FPWD
<Dimitris> yes I can try
<Dimitris> scribe: dimitris
Arnaud: the agenda is about the test suite but we need to capture some resolutions before the break
<Arnaud> PROPOSED: Review and raise issues against the revised ldom proposal by 26 February
<SimonSteyskal> +1
<cygri> +1
+1
<hknublau> +1
<iovka> +1
<kcoyle> +1
<hsolbrig> +1
<ArthurRyman> +1
<hknublau> I am not sure I still want to be one of the editors of the *Primer*.
<pfps> +0 because solutions to issues may raise other issues
RESOLUTION: Review and raise issues against the revised ldom proposal by 26 February (Chair's Note: rendered moot by change of plans regarding the draft)
pfps: I am not convinced but let's try and move foward
<Arnaud> PROPOSED: aim at publishing the revised ldom proposal as a FPWD within a week after 26 February, under a name yet to be defined, and recast as a spec (instead of primer) with annotations about all known issues
<hknublau> This is not realistic to turn it into a spec that quickly.
pfps: We should publish early enough, this document will need review
Arnaud: the documents have been around for some time
ArthurRyman: There are some missing sections
<pfps> there is a lot of work that needs to be done on this document
<hknublau> +q
hknublau: Are we talking about a primer or a spec. For feedback a primer should be sufficient
<cygri> "very rough early draft spec with proper definitions still missing"
Arnaud: Let's take this as the basis of the spec with a disclaimer at the beginning
<cygri> "with lots of red boxes to flag missing bits or points of contention"
<cygri> Specs with many examples are good IMO
hknublau: I could agree to that but a spec does not contain that much examples
Arnaud: This will be worked in time. By our charter we should publish a second WD by March and we are too late
s/ y o/O/
pfps: The work is draft and the public will not be able to provide proper feedback
<pfps> The problem that I see with publishing something that can be produced in a couple of weeks is that the document will give an incorrect notion of where the working group is going.
Arnaud: If we cannot make it we have to come up with an alternative plan
pfps: People should have a good idea where the WG is going and I don't see that
Arnaud: we should point at our issues so that we don't send the wrong message
ericP: we have to publish every 3 months, we are late and can get in trouble
(arguing about publishing the UC&R instead)
Arnaud: the document we need to be turned into two documents the primer and the spec
ericP: I'll see what I can do in a week
Arnaud: Let's wait until we're done to review and raise issues
<pfps> A spec can have examples.
Arnaud: the animations can be distracting in the spec and probably fit better in a primer
<pfps> I don't think that using UML in the document is good idea.
<hknublau> +q
ericP: instead of a UML diagram should I put a graph?
Arnaud: editors can choose
hknublau: limit examples in the spec
<cygri> reclass?
<hknublau> :)
<ericP> reshape into something more classy?
<SimonSteyskal> :D
<labra> http://labra.github.io/Haws/ldom/index.html
labra: I prepared a document for the semantics of ldom
... I also have a Haskel prototype
<cygri> Looks like we can publish an implementation report already
<pfps> Does this cover recursive shape recognition?
labra: I need feedback
Arnaud: let's switch to the test suite
... it is an important part of the recomendation
<hknublau> +q
Arnaud: we need to document how the test suit looks like and way for people to report the their testing
<labra> +q
hknublau: I have a draft for that on the ldom repository
... there are two types of test cases, one to test individuals and one the test a whole graph
<labra> http://shexspec.github.io/test-suite/
labra: I also have a test suite for ShExc
<hknublau> (Spec that I just talked about http://w3c.github.io/data-shapes/data-shapes-core/ldom.ldom.ttl)
<Zakim> ericP, you wanted to talk about the SPARQL, RDB2RDF and RDF1.1 tests
labra: it is in compact syntax but can be converted to RDF
<pfps> http://labra.github.io/Haws/ldom/index.html appears to have a error in the definition of Or simplification
<pfps> ... and it appears to have a very unusual definition of And
ericP: in RDF and SPARQLwe have manifests that contain different tests, I will show how this works and Holget can convert his test suite in this format
... we have a common test suite and common test format
<labra> http://www.w3.org/2011/rdf-wg/wiki/RDF_Test_Suites
<labra> that's the link to the documentation of the test suites
<cygri> +1 for CLI
Arnaud: the critical part is the test suite format and the report format
... Someone should take the lead here and provide a proposal
... it doesn;t mean that he will develop all tests but will have a leading role
*yes?*
<pfps> As far as I can tell the semantics in
<pfps> http://labra.github.io/Haws/ldom/index.html can't count correctly.
<pfps> This is because RDF graphs are sets and counting works by adding a triple to
<pfps> a graph. You can keep on adding the same triple to graph while counting it
<pfps> each time it is added.
I also have some work in this: https://github.com/AKSW/RDFUnit/tree/master/rdfunit-validate/src/test/resources/org/aksw/rdfunit/validate/data
<hknublau> +q
Arnaud: Is it a good time to talk about the name?
<pfps> Good! Let's do something non-controversial.
<labra> pfps, I am not sure what you say...maybe you can send me an email clarifying what you mean?
<pfps> sure
Arnaud: we also have issues on requirements
<cygri> Holger could host the next F2F ;-)
<hknublau> yes!
Arnaud: what should we talk about next?
<hknublau> https://www.w3.org/2014/data-shapes/wiki/Technology_Name
Arnaud: let's talk about the name
<hknublau> I like Boa but I am worried about the findability on Google etc.
<cygri> SRCL? Pronounced "Circle"
Arnaud: I like CONSTRAINTS
ericP: The most precise would be RDF Graph Contraints
hsolbrig: I am worried about using the word constraints
<pfps> We could use RDS (RDF Data Shapes)
(cannot hear very well)
now yes
<cygri> SCL? Pronounced "Shackle"
<michel> i like Boa
ArthurRyman: we won't find a nice acronym, let's look at turtle, let's use boa
<SimonSteyskal> +1 for boa
<SimonSteyskal> http://aksw.org/Projects/BOA.html
hknublau: are there any restrictions from W3C?
<SimonSteyskal> with boa rdf you find the aksw research project called boa
*what about sea turtle?*
<cygri> SHACL - Shape Checking Language
<labra> I proposed "SHAR" (Shapes for RDF)
<cygri> Codename? How about "Shapes"?
why not RDF Shapes
<ericP> +1 to SHACL
<ArthurRyman> +1 for SHACL
<cygri> SPARQL and SHACL
<TallTed> https://www.nationstates.net/nation=shacl
*hard to scribe*
<hknublau> SHACL is cool, but prefix probably too long.
<hknublau> Imagine shacl:sparql
<SimonSteyskal> [brainstorming about potential acronyms]
<hknublau> Prefix may be something else, e.g. "s"
<SimonSteyskal> but the association with shackles around rdf data is nice though
<labra> SHapes Constraint Language ?
<labra> Possible acronym....
<labra> +1 for SHACL also
<cygri> "NationStates is a nation simulation game. Create a nation according to your political ideals and care for its people. Or deliberately oppress them. It's up to you."
<ericP> aichteeteepeecolon...
<Arnaud> PROPOSED: Adopt "SHACL" as the name for our specification
<SimonSteyskal> +1
<ericP> +1
<iovka> +1
<ArthurRyman> +1
<labra> +1
<hsolbrig> +1
<cygri> +1
<hknublau> +1 but the prefix needs to be another question
<kcoyle> +1
+1
<TallTed> +1
<SimonSteyskal> i guess he is reading the document about semantics of LDOM
<SimonSteyskal> *SHACL
RESOLUTION: Adopt "SHACL" as the name for our specification
Arnaud: some people are missing but can object later
<SimonSteyskal> but then it's maybe pronunced wrongly
<cygri> no one has claimed http://prefix.cc/sh
neither http://lov.okfn.org/dataset/lov/vocabs/sh
<hknublau> sh is good
I like sh too
<labra> +1 for sh as prefix also
<cygri> http://prefix.cc/popular/all
<cygri> i am
<Arnaud> PROPOSED: Use "sh" as our prefix
<cygri> once we have the expanded URL
<hknublau> +1
<cygri> +1
+1
<SimonSteyskal> +1
<iovka> +1
<kcoyle> +1
<hsolbrig> +1
<labra> +1
<ArthurRyman> +1
<ericP> +1
<TallTed> +1
RESOLUTION: Use "sh" as our prefix
Arnaud: let's stop here
... we tackled the name issue and have three things left for tomorrow
... the next meeting, address Peters' mail and requirements
<Arnaud> trackbot, end meeting
<cygri> thanks all!