See also: IRC log
<Arnaud> hello there
<Arnaud> we're still waiting for people to show up
<Arnaud> trackbot, start meeting
<Anamitra> do you have the call-in number?
<Arnaud> anamitra, that's the code: 26633
<Anamitra> I am sorry is there a 800/888 # ?
<pfps> no 800 number for Zakim, however there are numbers in various countries
<Arnaud> Zakim teleconference bridge (+1.617.761.6200) with a code of 26633#.
<Anamitra> thanks
<simonstey> i'll be a few minutes late
<Anamitra> 978.899.aaaa - Anamitra
<Anamitra> I am on phone
<AxelPolleres> scribe: AxelPolleres
self introductions...
<ericP> ericP: ericP, W3C staff contact
<ericP> AxelPolleres: Axel Polleres, university of @@1
EricP (W3C), Axel (WU), David Martin (Nuance), Arnaud (IBM, chair), PPFS (Nuance),
scribe: Nick Crossley (IBM)
... Fabien Gandon (INRIA)
... Amy Guy (Univ. Edinburgh)
more on the phone...
Anamitra (IBM),
scribe: Holger Knublauch (TopQuadrant)
Arnaud: no one else on the phone
... Ralph Hodgson (TopQuadrant) also arrived in the room.
Arnaud: need good planning with the meeting, discussed before with EricP
... working on use cases and requirements is the most important
... other WGs are chartered with a fairly well-defined direction, in our case, see the discussion on the mailinglist: we made the charter more neutral in order to make it acceptable.
... people in the room with different assumptions, but we should come in with a fresh mind, need to agree whatthe problem is, have one solution in the end.
... fix terminology to understand each other, that's the goal of this meeting, plus learn about each other.
... my reading of the mailinglist shows that people have certain use cases in mind, but it's not yet agreed in the group.
... eric will give us an overview of the current "space".
... agenda for today, get an overview, sort out what are the low-hanging fruit, what can we tackle.
... for eric's talk, please let's refrain for debate for the moment, but let's focus on just clarifications.
Ralph: can offer facilities for screensharing
Arnaud: we make sure to let people on the phone what slides we're on.
ericP: we can use talky.io, check it in the break
Arnaud: please use the queue
<simonstey> is there a way to connect to the telefonbridge via sip?
Karen Coyle (DC) also joining the meeting.
<Arnaud> sip:zakim@voip.w3.org
ericP: explaining the motivation, we want to describe the interface, i.e. graphs that are "allowed" that's effectively validation.
... slide 2
<simonstey> http://www.w3.org/2014/Talks/1030-shapes-egp
ericP: errors would be e.g. date constraints, typos, etc. motivation is to catch such errors
... Orri Erling mentioned to me that he was looking for something like this for optimization purposes.
... competing with the SQL constraints world, XML Schema languages, in some sense
... in conventional data ontologies are separate from constraints.
... other languages, eg. OSLC keeps constraints separate.
... party invitees or patients might have different constaints on foaf:Person data.
... objects of some properties could be sometimes strings or objects (e.g. dc:creator).
... we want the ability to descibe/accept that inour constraint language.
... another example is enumerated sets for values.
... substrings, regexps for literal values,
... certain sets of values with an exception list of disallowed values.
... schema.org does not use intersection of domains (as e.g. rdfs:domain/range do).
... probably union
pfps: it's undefined in schema.org
ericP: objectproperties aren't strict, can be literals in schema.org ... so schema.org is different from the RDFS.. world
... existing technilogies include SPARQL, SPIN, etc.
Ralph: firstly, we need a reporting schema, secondly, we need relaxation rules
EricP: I can write enforcement of min/max cardinalities in SPARQL ASK queries.
... either explicitly or compile it from something more high-level.
... there's various differnent ways to write SPARQL queries that are equivalent.
... instead of ASK queries, you could also qrite queries that give you an error.
... slide 7, the system by Simister, Brickley is simpler, e.g. doesn't allow cardinality constraints, is still idiomatic, used by google-folks, but not endorsed.
... slide 8, SPIN... essentiually SPARQL in RDF
... slide 9 has a turtle graph with constraints in SPIN
... can "parameterize" the queries and add rules, SPARQL CONSTRUCT, still a declarative model.
... underspecific rdf:type arcs are problematic.
Ralph: you can do subsumption in the rule attached to the constraint.
<hknublau> (or use named graphs to keep contexts separate)
ericP: slide 10, OWL, growing community understanding OWL, small commmunity what OWL in open world means.
... e.g. OWL can't ever tail you whether a minCard constraint failed.
... slide 11: OWL reinterpreted as closed world.
AxelPolleres: Is that the same that PelletIC does?
pfps: now startdog, stardogIC is the implementation of this.
... foundation is any OWL axiom can be read as constraint/translated into SPARQL.
DavidMartin: any path for standardization for this?
pfps: RPI no W3C memberat the moment, the IP would be theirs.
Arnaud: evren sirin presented this in our workshop, but didn't push on broad adoption/standardization of it.
... but later it came up again during charteing process.
<pfps> my comments on other's IP cannot be taken to be authoritative
Ralph: if you stay in the RDF/SPARQL world things get ttreated differently.
AxelPolleres: Would it be interpreting OWL as SPARQL queries under OWL entailment as per SPARQL1.1 spec?
pfps: rather RDFS entailment regime
AxelPolleres: that's not something probably we can just take off-the-shelf.
pfps: does the IC implementation cover corner-cases?
... think stardog does RDFS completely, not sure.
ericP: kendall proposes to use manchester syntax.
<pfps> s/stadog/Stardog/ - not StarDog
ericP: on the plus side this is what many people understand when reading OWL axioms.
... on the other side no things such as date comparison or complex builtin functions, etc.
Holger: about slide 12... SPIN ressoucre shapes is just SPIN templates
ericP: slide 12 is SPIN as templates
... for something complex like date constraints, we need extensions of that.
... slide 13 Shape expressions
... mix of languages.
... Z notation.
... I added things like ‘or', semantic actions, not too much takeup yet.
... has a defined extensibility mechanism.
slide 14 several of the introduced approaches for one consistent example... should all capture the same intuition.
ericP: issues slide 15 e.g. interaction with reasoning.
... exmple of IinverseFunctionalProperty in that slide.
... shows there are cases where you want inferencing before validation.
... XML schema is much clearer about type annotation.
... a lot of the magic in Xquery comes from the ability to statically check types.
... question whether we want to support anything that adds stuff (rules? owl inference?) on validation.
... SPARQL regular expressions are much more limited than Perl/PHP reg exps.
... talking about http://en.wikipedia.org/wiki/Unique_Particle_Attribution
... more achallenge for XML Schema than for regexps.
... context-free = per property/object, context-sensitive = per property/objects in a certain context
... questions!
Arnaud: advice from the XML Schema community: be careful what you allow, it might blow up.
Michel Dumontier: just entered the room (short self intro)
scribe: we would like to use Shapes
timbl: just entered the room
... do be minimalist, but then don't take a long time
AxelPolleres: my questions...
... 1. often needs rules/views to make it easy to write constraints more concisely
... 2. vs. ASSERTION/CHECK ... we have no distinction between tuple-"borders".\
... 3. something in the JSON space we need to look at? is there schema-languages for JSON(-LD)?
... 4. when should those constaint be checked (UPDATE)
... 5. what about updateing constraints? what does it mean?
Ralph: the beauty of RDF/SW is that we can query data along with the model.
<fgandon> Ralph: should shape be queryable? e.g. SPIN allows reflecting on the constraints and querying them
Sandro Hawke also joined the room/meeting
<sandro> hknublau, try going to https://talky.io/shapes
thought this might be interesting/related somehow... http://www.aaai.org/ocs/index.php/AAAI/AAAI14/paper/viewFile/8487/8531
<kcoyle> scribe:kcoyle
After break: 10:30
Dean allemang introduces himself
On screen Hierarchical view of DC requirements for RDF Validation: EricP's version
DC has begun use cases and requirements
looks overwhelming; but Eric has grouped the requirements
Go through Eric's "small group" to see if we can come up with a core
<ericP> scribe: ericP
kcoyle: Dublin Core decided to work on RDF validation.
... relates to past (pre-RDF) work on "applications profiles".
... it was never heavily used.
... the DC RDF Validation WG started a couple months ago.
... Thomas Bosch had already created a database. We adopted it.
... We created a subset called the "Dublin Core" reqs from Europeana and a couple other things.
... You can view the DC reqs in the database [look on the far right next to requirements]
... We are winnowing the list down, e.g. "cardinality"
... DB is in Drupal. is continuously updated.
dean: [re XML baggage]
... folks are using XSD over OWL/XML
... has a good pedigree, fits in stacks. there's a baby in that bathwater.
kcoyle: the "baggage" i referred to is not that it's XML; it's that it's based the dublin core abstract model.
<kcoyle> scribe: kcoyle
ericP: showing the database (his)
<sandro> kcoyle: THey use "non-literal value surrogate" instead of "object"
added in the requirements form the validation workshop last year
<ericP> small reqs
<Arnaud> http://www.w3.org/2014/10/rdfvalreqs/?+Gsmall
<AxelPolleres> +q to mention work about RDF normal forms (whenever it fits)
ericP: suggests we got through small first, to see if we can get agreement
<hknublau> +q
pfps: concern that we are looking at requirements before doing use cases
<ralphtq> +q
<Zakim> AxelPolleres, you wanted to mention work about RDF normal forms (whenever it fits)
AxelPolleres: put a link in irc to a paper comparing relational model and rdf; this could be a use case
... e.g. foreign key constraints, etc.
... we should think about it
ericP: there is another hierarchy in the DC database
<ericP> case studies
<AxelPolleres> would extending R2RML to SQL constraints be a use case for us?
<ericP> Europeana Use Case
<AxelPolleres> (I guess that summarizes my question best)
<DeanAllemang> We can't hear Holger at all when he really has amnything interesting to say :)
Holger: believes requirements started as DC requirements; additional ones were added. Shouldn't call them DC. Examples called SPIN should be called SPARQL requirements.
<DeanAllemang> No, he always talks that way :)
Holger: thinks we can agree on minimum profile (small set) -- one way to define a minimum language is to list rquirements; another way
... is to define it as SPIN
... no extensibility in what is here, and this is the most important requirement
... minimum profile should not be the only outcome of this working group
Arnaud: this is just a starting point; this is not where we will stop
ericP: agrees they should be called sparql; SPIN templates are same as Shapes
ralphtq: Process point: upstreeam from use cases are customer needs; "solution envisioning" begins way before use cases/case studies
... expression of need/pain. wants to divvy things up into needs
... use cases too far down stream
Arnaud: this is an important point; open to this; we can backtrack
... we did this on a shared pad at the validation workshop; then we re-organized it all.
<ericP> hknublau, i just s/SPIN/SPARQL/'d. reload.
<hknublau> @ericP thanks!
michel: needs framework for what information is required from his group to articulate their requirements
DeanAllemang: for those who haven't been in discussion, a story-telling session would be helpful; stories could be discussed in terms of relevance
Arnaud: use q system
ericP: go through a few to help us tell our stories
<Zakim> ericP, you wanted to say "we should dive deep for a moment"
ericP: small group of requirements:
... high level requirements
<ericP> small reqs
ericP: to help us tell stories
... high level from workshop and DC
... language should be higher level than sparql
... under that: basic use cases covered by a constraint language implicit extension
... high level vocab for common cases
... constrains for different uses don't conflict
... syntax: concise language
... extensibility
Arnaud: extensibility was outcome of workshop; so,ething easy that does the 80-20, but can be extended for corner cases
ericP: bar for extensivility not high
... addressable schemas & addressable constraints
... be able to re-use constraints and have stable constraint identifiers
... ui generation - this is above what you get from RS or OWL; will require ordering of constraints
<Anamitra> We do that same (generating UI and validation code in js) in IBM (C&SI) - using Rsource Shapes
pfps: this seems to be a different kind of thing - language should be higher than sparql, then we have a use case for how it fits
ericP: foundation: schemas aren't in ontologies = schemas are separable from ontologies
... don't put constraints in vocabularies - leads to problem
pfps: could conclude that the only thing you have in an ontology is a listing of terms
ericP: owl ontology is talking about something different in terms of constraints
ralphtq: uses graphs; schema needs an adjective before it as does graph; need to pin down the word ontology
DeanAllemang: confirms that stories and use cases fall into two categories: data comes out good/bad. the other is expectation control
<Anamitra> in RDF we have resources refer to a network of resources - ideally I would like the constraint language for these resources refer to each other
ericP: at separation of constraints and onto semantics
... RDF target constructs - probably want to talk about triples and graphs
... a lot based on language tags
DeanAllemang: that sounds like SKOS functionality; SKOS may have been translated to SPIN (ask Ralph later)
<DeanAllemang> SKOS constraints have been expressed in SPIN. I don't know what percentage of the constraints were expressible.
<hknublau> Yes, we have implemented all SKOS constraints with SPIN.
<DeanAllemang> I thought so - I wasn't sure if you made it to 100%
ericP: Expressivity: or pattern, and pattern; original db had more detail
... lexical patterns - catch date/time errors; something must be of a certain datatype (Peter; value for predicate has to belong to...)
AxelPolleres: also need a negative
<DeanAllemang> Value Sets are important in finance reference data as well.
ericP: value sets: value must be assigned or unassigned
<AxelPolleres> AxelPolleres: you can us FILTER( ... IN ... ) for enumerations
ericP: cardinality: option, one or more, zero or more, but what about between 2 and 5? or bigger than one?
... have to decide if any minimum or maximum, or if there are a limited number of choices
<AxelPolleres> +q going back to SQL constraint and their coverage.
<AxelPolleres> It looks to me that the requirement to capture contraints coming from relational data are not entirelty captured here (i) CHECK (comparison/boolean expression on values attached to a resource), (ii) NOT NULL, UNIQUE (as special cases of (inverse) cardinalities?) (iii) REFERENCES/FOREIGN KEY (the question is with what to parameterize this... with a SPARQL query again?) ... should IMO be covered, How about multi-attribute FOREIGN KEYs?
ericP: protocol/invocation - does a class fire off validation? closed shapes - things can have only the listed properties, or if it can be an open shape
... associated constraints with particular datasets and associating with rest apis
<DeanAllemang> There are also privacy / entitlement issues about "closed shapes" - we don't allow spurious triples in to our data set, in case this is part of some elaborate attack.
<hknublau> @Axel I agree we should cover primary keys
ericP: implementability: how hard is it to implement the language? = has to be reducible to sparql, but cannot do recursion
<Anamitra> correction: Resource Shapes is schema for RDF data - not WSDL
<ralphtq> +q
ericP: huge call for validation with sparql
<michel> +q
ralphtq: does recursion using spin; but not sparql
DeanAllemang: Another kind of requirement: "OWL is a dirty world" why? How many new technologies do you make users learn? "relationship capital"
... = social capital" - costs a lot to bring in anything new; "adoption barrier"
... requirement: can get it adopted - "adoptability"
<SumitPurohit> Hi All, I am Sumit Purohit. Trying to connect remotely...IS "742737#" valid code ?
Arnaud: "try to keep it simple"
<simonstey> 26633#
<simonstey> @sumit
michel: language should be concise, but not so concise as to be arcane; and should be familiar to existing practioners; comprehensible
<SumitPurohit> got it...Thanks
<SumitPurohit> Thanks @simonstey
AxelPolleres: add to cover relational database data requirements? surface language may need relational requirements
... unqiueness isn't there
... references, foreign keys... can these be covered? for RDBMS to RDF (and reverse) should make these simple to do
<ralphtq> +q
ralphtq: what is a good story? protagonist, revelation of pain point, a challenge or barrier, and a happy ending :)
DeanAllemang: protagonists: modelling team; pain point: because it's a new tech, people say "the model is broken" -- what does that mean?
... sometimes it does mean that the model is broken; need to run the model through tests
... resolution: need a standard way to test and validate
pfps: you're saying that the documents you want to validate are representations of the models themselves
[people start speaking sparql and rdfs -- oh let's move on]
pfps: you want to generate a language model; coming into that are many entities; with their types and names
... just saying that an entity has a name not enough: every THING has to be provided a name that is a string
... we don't want to say that there is only one name
michel: we have three main use cases:
... w3c health care group; community profile for data sets
... group each said what data elements they had; these were collected and vocabularies were studies, so people would use the same elements
... argument for interoperability; has usual ones, but have to look at what is in the data itself; discoverability; wanted more documentation; and for the data
<ralphtq> +q
michel: to work when aggregated
<michel> http://tinyurl.com/hcls-dataset-description
ralphtq: owl import - brings in everything or nothing; you are asking to partially import something
michel: showing diagram from ttp://tinyurl.com/hcls-dataset-description
http://tinyurl.com/hcls-dataset-description
michel: need versioning which was not in void; and also didn't have all rdf data sets
... serves as an element guide
... check if identifiers are valid or not; check patterns (regex); url access pattern
ralphtq: can be done as mergeable graphs or layers of graphs
ericP: different validation levels
michel: can implement at different levels depending on what data you have and what you can provide
<Nick> +q
Lunch Break
<Arnaud> welcome back guys
<pfps> scribe: pfps
Nick: a triple store with a large number of input streams, with little control over them
... want to have a query builder that others can use to produce reports
... want to describe the (likely) shape of the data so that users can build queries to produce pretty report
<DeanAllemang> Are we building a query or building a report from a query?
<ralphtq> a query builder
Nick: the shape controller suggests that the new data looks a certain way
... so that the reports still work OK
Sandro: how about constraining the input tools
Nick: that can't always be done
... the shape should not be tied to a particular type (or vice versa)
ericP: shapes can be attached to datasets and services
... want to say that an LDP container has a certain shape
<AxelPolleres> AxelPolleres: shapes could be attached to resources that again are identified by a (one variable) SPARQL query
<Anamitra> shapes can be attached to an instance of the RDF document - to describe constraints for that instance
<hknublau> We could add spin:type in addition to rdf:type.
ralptq: every RDF resource has a type - rdf:Resource
ralphtq: the interesting part of this story is that types change
kcoyle: there is also the notion of completeness here
Nick: OSLC shapes are not a complete solution to this problem
... the shapes describe how the future data is likely to look
ralphtq: what about large sets - like countries of the world
Nick: shapes should point to external resources for this
david: doesn't an ontology solve this problem?
Nick: you can't express all the constraints you want that way
... there is also the constraint vs axiom issue
<Zakim> ericP-web, you wanted to tell an IssueShape story
dean: want to express expectations, not requirements - we use min 0 for this - this is a convention
ericP: consider a (REST/nonREST) endpoint that coins new issues
... the endpoint provides a shape for the constructed node
... these nodes go through several statuses - e.g., from reported to resolved
... the constraining shapes change as the status changes
... nodes can have multiple purposes, e.g., as a reporter and a responder, and have to meet the shape for both
dean: was there inferencing going on?
ericP: no
dean: but what about that reporter node?
ericP: this was not done using inference
axel: story from project with Siemens - configuration management, particularly combinations of configurations from different systems
<AxelPolleres> https://ai.wu.ac.at/~polleres/publications/sche-etal-2014ConfigWS.pdf
axel: needed to express constraints on the configurations so that they would mesh
... also needed identify management, i.e., owl:sameAs symmetric transitive closure
... also wanted to be able to reuse components, e.g., path expressions
<hknublau> or SPIN functions
<ralphtq> +q
ralphtq: EPIIM project - handling data coming from oil exploration
<dallemang> http://www.epim.no/epim/main/home
ralphtq: need access control on the data
... authorization is via SPIN constructs
eric: shapes as a selector for what can be seen?
ralphtq: yes
dean: tag data with various aspects - control is then by aspect
<Nick_> +q
Nick: decorate eric's story
... use the shape to describe the input data to constructors
... the output data could have the same type but a different shape, e.g., includes system-added information
eric: for example, some constructors forbid certain kinds of information on inputs, but provide them on output
dean: want to require that a time interval has a specified end time, e.g., for particular kinds of contracts
... so some kinds of contracts (e.g., bonds) can have an open end time, but others need to have a provided end time
<ralphtq> +q
dean: so some kinds of contracts can have an open end time, but others (e.g., bonds) need to have a provided end time
ralphtq: constraint checking of values at user interfaces, e.g., internal form of some strings, e.g., different values for different properties
... importing large ontologies is too gross, only want parts of them, so copy them in and use seeAlso to point to source
... can shapes solve this?
<Zakim> sandro, you wanted to tell a story
dean: maybe, maybe
sandro: decentralized storage of short posts using linked data
... how do we describe how this data looks / how it looks when produced / how it looks when consumed
dean: perhaps want several levels of this description
sandro: maybe not for this application
arnaud: schema.org validation, i.e., a way of describing page data so that it will be nicely processed by search engines
sandro: or a way of describing potential actions so that they can be turned into real actions
arnaud: what to do with these stories
ralphtq: allocate use cases to these stories
kcoyle: there is not yet full coverage of the short list, nor are these covered by the short list
<ericP-web> Pirate Pad for who knows what?
<ericP-web> pfps: stories are nice but mutable
<ericP-web> ... it would be nice to capture an example of the story
pfps: so that we could know when a story is being covered
eric is creating a list of the stories
ralphtq: should we split up
ericP: probably not
arnaud: let's fix up the pirate pad stuff
<ericP-web> Pirate Pad for stories
<ericP-web> Pirate Pad for stories
lots of typing on the pirate pad
the pirate pad has the stories and some organization and some examples
Dean: can we go over the small requirements and see what we think of them now
ericP: there are some things in the small requirements that haven't showed up in the stories
dean: most triple parsers complain if they see invalid data, so this kind of checking is somehow covered
ericP: but this doesn't cover comparison of data values, e.g., date comparison
ralphtq: OWL 2 has the ability to do value ranges and unions
axel: what about validating RDF constructs, e.g., lists
dean: problems in lists have shown up in the real world
<Zakim> ericP-web, you wanted to say that we also may want to validate things which are lists, and the things in lists
eric: what about typed lists, e.g., a list that is supposed to be all people, or all people with names
ralphtq: is this leading to an ontology of data structures?
eric: recursive checking can recurse down lists
<hknublau> @Arnaud yes well, thanks for asking
<hknublau> For future reference, talky.io dropped off a few times and was not too reliable, but at least easy to run and "install".
<SumitPurohit> aacc is me
<SumitPurohit> zakim: aacc is me
<kcoyle> SumitPurohit: we're on a break until the half hour.
<SumitPurohit> oh....ok..i will join after half hour
<kcoyle> ok, see you then
<Nick> scribe: Nick
<Arnaud> chair: Arnaud
<kcoyle> http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=requirements/dc-requirements
<Arnaud> agenda: http://www.w3.org/2014/data-shapes/wiki/F2F1#Thursday
Reviewing dc requirements to see if we missed anything
dc requirements include ordering constraints - ordering between and within resources - the order in which things must be encountered in the data set
state of dc reqs - data gathered, but now needs sorting, triage, etc.
Discussion about whether that example of data ordering is one we might not want to address in this wg (and what that ordering means in the first place)
kcoyle: dc application profiles might go beyond shapes, adding such things as ordering constraints
<SumitPurohit> +q
ralphtq said some telemetry payloads are very order-sensitive
<ericP> http://www.w3.org/2014/Talks/1030-shapes-egp/#%2814%29
ericp on slide 14 could add ordinals to resource shape
SumitPurohit adding ordering to RDF has proven problematic
<AxelPolleres> +1 to not mingle ordering/output with validation... something which checks order of triples is NOT inside RDF.
kcoyle also need versioning
<AxelPolleres> ... whatever needs order should be packed in a list, IMO.
and administrative information
<hknublau> @Axel we often use xy:index properties for ordering.
<AxelPolleres> hknublau, that's totally ok, but that's NOT ordering of triples... that is a constraint that this property has to be unique and consecutive per resource.
Nick is lead of OASIS OSLC configuration management, perhaps we can share some of the efforts there
<AxelPolleres> ... which is something completely different.
<hknublau> Yes I am just wondering whether we can agree on a de-facto standard property for ordering, and then use this in reusable constraints (if that's ever a requirement). Many people dislike rdf:Lists and then it
<hknublau> is often possible to have a single child index if you have a single parent...
<hknublau> (just a scenario that we encounter often).
<AxelPolleres> fair enough.
kcoyle want human readable documentation - comments are not enough -- may need link to something else (using skos, open annotation, ...)
<SumitPurohit> +q
kcoyle requirements to specify presence of a language tag, or literals with a certain set of language tags - must have at least English, French, German.
Discussion about character encoding issues - copying and pasting text from Microsoft Word
<AxelPolleres> Sounds to me we are talking abotu two different use cases here... a) validate that the data complies to some shape(s) b) get all data out that complied to a (set of) shapes, the latter is addressed (partially?) by http://www.w3.org/TR/sparql11-query/#constructWhere
dallemange told story about translation of Russian names causing problems
<AxelPolleres> ... but in fact not completely.
<AxelPolleres> ... no complex patterns allowed.
<Zakim> AxelPolleres, you wanted to ask what we are talking about :-)
<ralphtq> maybe we should note a requirement for character encoding constraints?
AlexPolleres two use cases for shapes - data validation, and extracting a subset of the data matching some shape - latter can be done using CONSTRUCT WHERE
^AxelPolleres"AxelPolleres^
<AxelPolleres> again, it can be done by CONSTRUCT in general, but CONSTRUCT WHERE is inconvenient for those cases.
<Zakim> AxelPolleres, you wanted to reemphasize that rules may be useful in connection with Shapes, but I'd be afraid to use OWL axioms here
Common theme to recent discussions - how far do shapes go? What is out of scope? We need a scope that can be contained in a reasonable timeframe.
ericP: R43 is a watermark for scope
... if we say our extensibility covers a given story, we are effectively saying shapes per se do not cover that story - what we define in the core shapes spec is key
cardinality: do we provide a limited set of choices (zero, 1, zero-or-more, 1-or-more, etc.), or allow arbitrary minimum and maximum - still open question
What is the least acceptable? Raw SPARQL presumed not good enough (though dallemang questioned even that) - add at least some templates and user interface
Arnaud: conclusion of the workshop was that SPARQL is not a solution - need something more declarative. This wg is not bound by that conclusion, but we should take it into account
dallemang: one example of something higher level - we want to be able to express recursion
<hknublau> +q
Resource Shapes and SPIN are both about the same "higher level" than SPARQL
hknublau: examples in ericP presentation are not optimal SPIN, and could be more compact
Previous statement applied to slide 8 - slide 9 is more representative
<SumitPurohit> what time @hknublau's presentation is scheduled ?
<hknublau> @Sumit I believe first session tomorrow morning.
<SumitPurohit> Thanks
ericP: can execute SPIN on slide 9 without a SPARQL endpoint, potentially much more efficiently
AxelPolleres does not like magic properties - hknblau agrees in most cases, and they should be made explicit - ralphtq mentioned they distinguish in UI by showing magic properties in bold!
hknublau: re execution in SPARQL or elsewhere - you have the choice, which is good
<AxelPolleres> AxelPolleres: my questions were: 1) do we gain something cmoputationally by defining a more abstract surface syntax? 2) don't like the syntax of magic properties, would like to make them ebing marked explicitly distinguished from normal properties - syntactic taste
ralphtq: different people, or different parts of the discussion, have examined the requirements from different points of view - will this requirement help us decide the technology? or is this requirement something to be addressed by RDF Shapes, or by Dublin Core?
dallemang: now we have talked a bit more about what "higher level" means, I am willing to sign up to that requirement!
<SumitPurohit> can we scribe what we mean "higher level"
<AxelPolleres> dallemang: some sort of higher level marcos to pull out and reuse things
<AxelPolleres> ... control infrastructure allowing for e.g. recursion
<AxelPolleres> ... encapsulating functions
Some sort of templates, some sort of control infrastructure environment for recursion, encapsulate functions (third one not fully baked yet)
For templates, read definitional capabilities
Arnaud: does control infrastructure include things like inferencing?
PROPOSED: define R-103 as "higher-level language for 1. definitional capabilities, e.g. macro rolling up and naming, 2. control infrastructure for e.g. recursion"
<AxelPolleres_> personally, I would like it to have SPARQLish syntax, rather than TURTLish.
ralphtq_ wants to add the requirement that it be executable - dallemang and ralpthq_ agreed this was necessary but could be a different requirement
<ericP> +1
<dallemang> +1
<hknublau> +1
<pfps> +1
<ralphtq_> +1
<AxelPolleres> +0.5
<SumitPurohit> +1
<michel> +1
<kcoyle> +1
kcoyle: asked if the expectation was that the rewording of the requirement be accepted back by dc
<sandro> +1
ericP: that would be nice, but not absolutely required, and that was a different process
+1
<AxelPolleres> Arnaud: Resolutions only stick when the minutes habe been approved, so late objections should be raised before the minutes approval.
RESOLUTION: define R-103 as "higher-level language for 1. definitional capabilities, e.g. macro rolling up and naming, 2. control infrastructure for e.g. recursion"
<AxelPolleres> ... resolutions can always be overturned when you bring in new information
Discussion about process - Arnaud described how minutes are published, then brought up for approval at next meeting - issues for votes, etc., are not fully resolved until after that approval
<SumitPurohit> +q
Discussion about tomorrow's agenda - we expect presentations on various technologies
Questions about whether or not invited presentations from non-members were out of order; the chair can invite such a speaker
pfps: will need 5 minutes plus questions - which might be a lot more than 5 minutes! Let's say 15 minutes.
hknublau: will need 20 minutes plus q&a - say 30
<AxelPolleres> expressivity of XSPARQL is considerably higher than that of GenX
<AxelPolleres> though, of course, lower than the more general semantic action
<AxelPolleres> mechanism in Shape Expressions." that's wrong (as XQuery is Turing-complete) ;-)
<AxelPolleres> oops.
Arnaud: reconvene at 8.30 - attendees should be here by 9
<ericP> scribe: ericP
PROPOSED: accept R-103 as a requirement
<SumitPurohit> +1
<Nick> +1
+1
<AxelPolleres> +1
<ralphtq_> +1
<sandro> +1
<pfps> +1
<hknublau> +1
<dallemang> +1
RESOLUTION: accept R-103 (as defined earlier in this meaning) as a requirement
<sandro> +1 assuming R-103 is defined as earlier in this meeting
<Nick> What we meett by the above vote is that 'Accept our rewritten version of R103 as a requirement for RDF Shapes'
PROPOSED: R111, "Basic use cases covered by constraint language", and R176, "high-level vocab for common cases" are redundant against R103
<dallemang> +1
+1
<SumitPurohit> +1
<ralphtq_> +1
<pfps> +1
<Nick> +1
RESOLUTION: R111, "Basic use cases covered by constraint language", and R176, "high-level vocab for common cases" are redundant against R103
Nick: defaults are important in LDPC; if you don't specify a property on an initial post, tyou get the default value.
dallemang: is this appropriate for shapes?
Nick: that's one of the primary use cases for OSLC
... tells what you have to specify and what you will get if you don't specify
<ralphtq_> +q
dallemang: in banks, we use rules like "if you don't specify X, we'll use property Y" (dynamic defaulting)
michel: do you want a temp object or populate the kb
<SumitPurohit> Are we saying For Ex. "First" name in an ontology should have a default ?
Nick: as ralphtq_ said, could be in a UI
ralphtq_: would be be doing defaults differently that SPARQL's COALESCE
dallemang: can use the property ":default" implemented as COALESCE
pfps: I wish to defer until seeing the use cases.
<SumitPurohit> :-) may be add me in that group
<Nick> scribe: Nick
Discussion about conciseness and human readable - all agreed this was difficult to define and measure, However, we do need to define our audience.
<ericP> scribe: ericP
PROPOSED: accept R184 defined as "concise language" as a requirement
+1
<Nick> scribe: Nick
sandro: there is value in keeping a requirement for conciseness, even though we cannot necessarily define it precisely
<dallemang> +0
<sandro> +1
<ralphtq_> +1
<ericP> +ε
+1 (useful as a communication of our intent)
<SumitPurohit> +1
<ericP> scribe: ericP
RESOLUTION: accept R184 defined as "concise language" as a requirement
<michel> +1
<AxelPolleres> +1 (late)
<ralphtq_> +q
pfps: RDF-izing the structure might be going a little far
<Nick> scribe: Nick
Nick: I want the shapes to be queriable, and to be able to annotate them with (e.q.) signatures, status, etc. Addressable is not enough.
<dallemang> adressible
<dallemang> queryable
<dallemang> parameterizable
ralphtq_: suggest adding parameterizable
<dallemang> Addressable is giving it a name so that we can use it again elsewhere
<dallemang> queryable means we can oopen up the structure, decorate, find, and layer shahpes
<ericP> pfps: "parameterizable" has two issues:
<ericP> ... .. 1 imposes a required execution strategy
pfps: parameterizable might lead to poor execution performance if done badly
... potentially changes the execution environment a lot (cf macros)
... could change a recursive language into an undecidable language
<ericP> ralphtq_: i'm worried about technical debt.
<ericP> ... don't want to people to use copy and paste
<ericP> dallemang: it sounds like "reusability" is the real requirement.
ensuing discussions about reuse strategies and implementation, and scolds for people straying into implementation!
<SumitPurohit> Everyone, Need to leave now....
+q
<SumitPurohit> See you tomorrow.
<SumitPurohit> "talk" to you tomorrow :-)
<ericP> scribe: ericP
Nick: you stopped short of what?
<Nick> dallemang: agrees to addressable and queriable as requirements, but stops short of parameterizable reuse
dallemang: "parameterized reuse"
... it's a laudable goal, but it's too ambitious
... "love to have"
Nick: when talking about queriable, i was talking about the shape as a whole, not bits of it.
... the shape as a whole be queryable, annotatable.
dallemang: does that meet uniprot?
michel: i don't think anyone's poking into the rule
<hknublau> Some people do walk SPIN RDF triples...
Nick: we did agree that we'd have functions or macros or whatever
<ralphtq_> +q
Nick: so we're only missing the parameterized bit
... having parts of one shape available for use in another shape may be beyond what i meant
ralphtq_: michel's comment made me think about testability
... test-driven development, e.g. for shapes to support requirements for testability
<Nick> Nick: would like to discuss use cases for parameterization further
dallemang: in FIBO, we're setting up testability, but we have no intention of using shapes for that.
<Nick> michel: addressable constraints would be really important
PROPOSED: accept R147 "addressable schemas" and R148 "addressable constraints" as requirements
+1
<Nick> +1
<dallemang> +1
<ralphtq_> +1
<sandro> +1
RESOLUTION: accept R147 "addressable schemas" and R148 "addressable constraints" as requirements
<SumitPurohit> late +1
<Nick> scribe: Nick
Discussion about what queriability means - discoverability (generally agreed), and querying the structure of the constraint - e.g., find all constraints that apply to this type
<hknublau> +q
We found that this may be implied by R183 on the dc list
<AxelPolleres> +1 to not make TURTLish syntax mandatory.
hknublau: cautions us not to go too far with an introspection capability - may make standardization more costly
... concerned about feasibility of implementation
... do not require that the metadata be in the same world graph as the data being constrained
<hknublau> Yes, see spin:imports vs owl:imports.
<ericP> scribe: ericP
PROPOSED: accept E08 "Discover shapes" defn: "annotate shapes and query over annotations"
+1
<Nick> +1
<dallemang> +1
<ralphtq_> +1
<pfps> +1
<sandro> +1
<AxelPolleres> 0 (will explain)
AxelPolleres: if it's a sparqlish syntax, we could generate the turtlish syntax, but are we chartered to do that?
<michel> +1
ericP: "so if we have addressable, someone else can do it"
dallemang: if it falls out of all of our proposals, we should take ownership of it.
Nick: we should define a shape for shapes
RESOLUTION: accept E08 "Discover shapes" defn: "annotate shapes and query over annotations"
<Nick> scribe: Nick
Meeting adjourned
<Arnaud> trackbot, end meeting