– DRAFT –
DXWG F2F3 - Day 1
08 May 2018
kcoyle: thanks Riccardo for organising the meeting
… short round of introductions
… first day introduction to ideas around profiles
… then we go on to discuss those ideas
… we want to do this quickly due to time constraints
… [checking who is online]
… we need to set well-defined goals
… We have the charge of doing three different deliverables, so we
… need to formulate what we want with profiles so that we can deliver
… need to be clear what a profile is
<danbri> mr_wibble, who are you?
<mr_wibble> Tom Baker
<antoine> It's Tom
<riccardoAlbertoni> The meeting is host by Italian National Council of Research - Institute of applied mathematics and information technologies
<antoine> can't you hear us?
<mr_wibble> This is the default I was given - will try
<danbri> type: /nick TomBaker
kcoyle: There is a definition of profile https://w3c.github.io/dxwg/profiles/#Introduction
… topic is complex
<danbri> tom, just visit irc.w3.org in a new tab abd come in with a new nickname, then close this one
SimonCox: Break it down to separate concerns
… should have a name and has as set of dependencies
AndreaPerego: Is this profile in general or application profile in particular?
<tom_baker> I'm not hearing anything now
<tom_baker> but I see the screen
kcoyle: [rewriting profile definition]
<Zakim> SimonCox, you wanted to ask about how we should handle the Q for people in the room
SimonCox: asks about using the queue since there are many people in the room
<PWinstanley> https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-Gks5dDa8n2B5IN6rWa3kRpo/edit?usp=sharing
SimonCox: and discussion tends to be livelier and the use of the queue slows
… things down
kcoyle: agrees, we'll have the open discussion later
PWinstanley: suggests using a GoogleDoc instead
kcoyle: can we accept this definition as in the GoogleDoc
… and move on
[work on the profile def in the GoogleDoc]
<AndreaPerego> Makx's presentation: http://makxdekkers.com/DXWG/DCAT-AP.pdf
kcoyle: Highlights that there are quite a lot of issues on the agenda
<Makx> http://makxdekkers.com/DXWG/DCAT-AP.pdf
kcoyle: that we need to address before the end of the meeting
SimonCox: Profile definition:
… 1 what it is, 2 what it does, 3 it has a name
Jaroslav_Pullmann: This is all about constraints but doesn't address
… how a new vocabulary is constructed by the use of profiles
… This we need to discuss. It's about the re-use of other
… vocabularies (subsets etc.).
PWinstanley: is the identifier necessarily a URI?
kcoyle: LarsG says it is
Makx: DCAT-AP was developed for European data portals
… [text is essentially in the slides]
… #5 the process used was very similar to the W3C process
… #7 kinds of questions, "what is the difference between publisher and contact point"
… #7 maintenance of profiles is an important part of the development
<SimonCox> @danbri - no
Makx: #9 some additions added from experience, some more forward-looking
… #10 much of the discussion in the group was about the
… mandatory vs recommended use of licensing information
… #11 one guideline is about how to extend the DCAT-AP profile
… e. g. which controlled vocabularies to use
… there is an analysis report to see how the national profiles
… differ from DCAT-AP
… #12 some of the properties that were thought to be crucial weren't much used
… whereas other optional ones found many implementers
… obviously some properties were confusing
<SimonCox> Does GeoDCAT-AP have dependencies on any named base specifications in addition to DCAT?
kcoyle: Thanks Makx, this shows the complexity of a real working
… profile. Suggests to do the discussion in the GoogleDoc
<SimonCox> https://github.com/w3c/dxwg/tree/gh-pages/profiledesc/examples#dcat-ap
SimonCox: has DCAT-AP WG been looking at formalisations, e g the one
… SimonCox posts?
Makx: What we have done is to try to describe the profile using SHACL
SimonCox: The is DCAT-AP currently documented?
<Makx> https://joinup.ec.europa.eu/release/dcat-ap-v11
Makx: Refers to the documentation site
… there are several formats (doc, rdfs, shacl, JSON-LD Context)
… SHACL is very incomplete (only checks mandatory fields, should be extended)
… to include other parts of the specification
SimonCox: Very cool!
<Zakim> SimonCox, you wanted to ask Makx if the proposed definition accommodates DCAT-AP? and to also ask if this proposed formalization makes sense https://github.com/w3c/dxwg/tree/gh-pages/profiledesc/examples#dcat
roba: All DCAT-AP experience has been captured in the requirements
… when you look at how things are connected (implementation resources,
… dependencies) it becomes complicated, this is what
… the profile description vocabulary is about
… and it captures those relationships fairly well (looking at the
… discussion).
<SimonCox> 1. formal vocabulary https://w3c.github.io/dxwg/profiledesc/profiledesc.html
<SimonCox> 2. example for DCAT-AP https://github.com/w3c/dxwg/tree/gh-pages/profiledesc/examples#dcat-ap
SimonCox: shows the profile desc page and some examples of how
… the vocabulary can be used to describe DCAT-AP and
… some Australian work
… The profile vocabulary has got tighter semantics than the
… description of DCAT-AP that was partially done re-using DCAT itself.
… It should be noted that the profile vocabulary is not only about
… RDF profiles but is more general
… The primary test case is DCAT
roba: Will test the vocabulary on some OGC work, too
… Picked out a few examples from Makx's page regarding
… hierarchies and versioning (hasn't looked closely at that yet, though)
kcoyle: Maintenance schedule and agency should be part of the vocabulary
roba: The vocabulary won't reinvent wheels, so maintenance might use
… another vocabulary
Makx: Maintenance might be more important for base specifications
… than for profiles. Change in profiles/vocabularies can be very
<roba> recommendations for maintenance and governance aspects? seems like wider context than profiles...
Makx: hard for people to implement
SimonCox: There is a type of resource (profile/specification) that has
… some additional constraints when we catalogue it
… That means that those who develop the profile formalisation need
… to look at how that maps to the DCAT backbone
… We need to look at how that relates to a DCAT catalogue, and that
<danbri2> (re cost of changes, sometimes creating new APs, or evolving existing ones, is a method for *avoiding* changes to the underlying rdf vocabs.
<danbri2> )
SimonCox: publisher and maintenance schedule should be mandatory
danbri2: What is the syntactic level of interoperability?
… There are groups that are concerned only with syntax (e. g. JSON-LD/JSON Schema)
… and don't understand e. g. RDFa
<PWinstanley> LarsG: context = profile negotiation work
... first- definition of a profile
second, what must be in the document
LarsG: profile should be identified by a URI, then have a human-readable title
… textual description, and perhaps a formal model
… Inspiration taken from ODRL work
… in Library work profile doesn't depend on media type, it is considered in a very abstract way
… We are making progress - but as danbri2 mentioned, communities differ in their interests and we need to find common ground
kcoyle: Do you 'see' the profile Rob and Nick create as fitting with your approach. How do we get these together?
LarsG: The neg group thinks the profile identifier is critical to the 'negotiation' bit
… then are there profile hierarchies, what dependencies are there?
… XML or OWL imports are there, why shouldn't this work for profiles
… the schema location vs the schema identification are very different, but in the XML situation this can be implemented in the engine
… the tighter linking simplifies the situation
roba: the profile descr vocab covers those requirements. The profile desc is agnostic about format
… the use of mediatype to describe the constraints is made canonical, so you can create a profile of the profile vocab to describe profiles
… there was a deliberate mistake in the vocab to include cardinalities - they should be taken out.
… the description can cover hierarchy, but I don't think it will achieve a lot.
<Makx> Too much echo
<Jaroslav_Pullmann> https://github.com/w3c/dxwg/issues/72
Jaroslav_Pullmann: there is a proposal for a description but we are losing the notion of 'function'. how does a profile behave - does it constrain or widen or re-define a psecification?
… there are examples of functions/purposes of profiles in the link
… when looking at the description bear in mind function
AndreaPerego: URIs are used in catalogue services - if not exactly uris they use codes
… the catalogue service knows about the codes and can handle metadata as required by the output schema.
<roba> profile of profile.ttl to define a canonical way to attach codes - eg. skos:notation ?
AndreaPerego: all the work on geoDCAT-AP etc was based around this - the URI is just an identifier, the catalogue knows what that identified entity is about
… there are many aspects, we need to address them one by one
kcoyle: yes we need to diagram these aspects
Jaroslav_Pullmann: we need to be guided by the function . e.g. constraints are a function. this would give a concrete aspect of specifying the mandatory elements
… Makx illustrated profile based obligations. These area fundamental requirements
<roba> implementation resources have a "role" - so a way to address these needs is provided
kcoyle: I will illustrate the basic framework
DC defined a framework putting the profile into a context (pre-RDF)
<danbri2> did RDDL come up? i think 15ish years ago, when xml namespaces were controversial.
<danbri2> ie Resource_Directory_Description_Language
... there was a profile mainly based on semantics; a vocab was developed to describe how the vocabulary of the profile is developed from the user point of view
... it is hierarchical
<tom_baker> http://dublincore.org/documents/profile-guidelines/
... we (Tom Baker and I) developed a setof guidelines ot help people develop their profiles. In DC a profile is a reuse of vocabulary terms (constrain, but not invent)
<tom_baker> http://dublincore.org/documents/dc-dsp/
... the concept in DC was to define vocabs very loosely and then fine-tune the constraints in profile
<tom_baker> http://dublincore.org/documents/singapore-framework/
... I've been working on developing a simple way for people to create vocabs using CSV on the web. Vocabs can be created on spreadsheets. We are focusing on the human end of this
... Tell people what needs to be input. What is happening in this group is at a lower level, other people who don't have the technical ability need a wrapper to simplify their efforts. We hope to link this to ShEx and SHACL
danbri2: It feels similar to the DC situation - e.g. DC agonised over link to RDF - so they did shex and shacl work indirectly in case RDF 'died'
… because DC is stepping out of RDF to keep things going
… e.g. RDDL in days of old
<roba> DC work fits in just fine as implementation resource - we are just promoting the metadata for such resources so we can have a canonical form to help us discover them and knwo how they should be used..
SimonCox: yes, similar to what Makx described in his list of distributions
<tom_baker> http://www.rddl.org/
SimonCox: the point danbri2 made last night about content negotiation - we want the published of a resource to describe what is available
… Landing pages give us the next step
… can this be accommodated in a machine readable form?
<kcoyle> https://github.com/kcoyle/RDF-AP/blob/master/schemaList.csv
danbri2: i don't know. conneg doesn't work for web crawlers - it causes a mass DNS as the sources get queried
SimonCox: we have seen dcat:distribution and in roba and Nick's prof:resource is used
… if you don't send content negotion a format it will send back the landing page
LarsG: do crawlers follow links?
danbri2: I'd have to get back to you on that
<roba> * yes hard to follow...
Jaroslav_Pullmann: we are a DCAT group but we're talking about defining profiles - we need focus
kcoyle: we nede to put these levels into the page to determine what our focus is going to be
<danbri2> I was referring to RDDL, https://www.xml.com/pub/a/2001/02/28/rddl.html
<antoine> https://docs.google.com/drawings/d/1dHkpwKwUwMgS1RqSCTPO3uOoRiY_qNk0z5bhXJlYi4Y/
antoine: asking about these different levels....I added to the agenda a proposal to capture at least some levels (wiki page)
… the diagram is to see if I've understood roba and SimonCox points and also to make my proposal
<tom_baker> I think danbri2 meant that DCMI did ShEx- and SHACL-like work, circa 2007-2008, but did it with a level of indirection in the form of an RDF-like model
antoine: I think it is a rewording of what has been proposed earlier
roba: looks accurate. it is a matter of chosing the right words. those elements exist with a little qualification to the specifications of what these elements 'do'
antoine: I don't go into the detail, but I'll start by explaining that the start is the middle layer
<kcoyle> Antoine's diagram looks very clear to me
<Zakim> LarsG, you wanted to ask if we're really (only) a DCAT group
LarsG: coming back to Jaroslav_Pullmann comment that we are a DCAT group - we are a DX group. DCAT is only one aspect
Jaroslav_Pullmann: when talking about profiles etc DCAT is a baseline - we don't have other stakeholders
LarsG: profile guidelines will be a 'recommendation' so we need >=2 implementations
… profiles is on the IETF track
danbri2: do you want web browser people to be involved reading the work?
LarsG: I don't expect that immediately, but perhaps in a few years time
… I don't think it is constrained to the semantic web community
kcoyle: where do you see the difference. semweb bleeds into other areas
danbri2: people think about other things than RDF
… if something comes out of this group others might want to consider if it is going to interfere with e.g. web server operations
Jaroslav_Pullmann: in LarsG proposal the focus was negotiation, not on the working of a profile.
LarsG: we don't expect IETF to get down into the detail of what a profile is, just the identifier
roba: the profile description is there but the negotiation aspect doesn't need to deal with the description, identifiers are enough
<antoine> roba+ yes profile negotiation just tells where to find things
AndreaPerego: we should go to REC track, but we might not do that. If we see that we don't have implementations then we can just go to a note
PWinstanley: three presentations have presented us with some options
… Makx illustrated requirements on basis of various *DCAT-AP versions
… RobA showed how this is a generalizable pattern, with DCAT as exemplar, but useful in wider setting
… Lars claims we need to right kind of identifier, but raises issue of scope - is this just RDF, or does it make wider claims. If the latter, it will take more work to get issued as standard
… now we need to understand what the priorities are
… so we develop working draft
… So, looking at definition: 1. 'profile accomplish a particular function'
kcoyle: developed profile for a reason
Jaroslav_Pullmann: 'does not define new terms or concepts' - only composed of elements from dependencies
kcoyle: agrees, and this is how DC does it, but some requirements point to adding new elements
PWinstanley: how different to SQL or XSD?
Jaroslav_Pullmann: asking what is special about 'profile' compared with 'vocabulary'
danbri: metadata wars ... DC=discover, XX=multimedia, YY=teaching etc
… if you re-used too much, then you can't show new artefacts to funders :-(
… Shape languages allow a new artefact that doesn't create new elements :-)
… JSON-LD supports aliasing - so JSON users have clean terms which map to existing terms from 16 different namespaces
kcoyle: DC profile is more than just a vocabulary. Useful for certain _applications_ = for humans and what they need to do with it
… includes examples, guidance, supports web-forms
… gets to function or reason-why
<Zakim> AndreaPerego, you wanted to ask if it may be worth having examples of such "functions"
PWinstanley: what is 'function'? Mathematical? Facilitative?
AndreaPerego: work from examples of existing profiles. Comes from practice, artefacts that you can claim-conformance-to
<Zakim> antoine, you wanted to suggest that any application would be ok as example
Jaroslav_Pullmann: importance is _identity_ of profile
antoine: conflation of profile and application profile
SimonCox: functional requirement is having a named artefact to claim conformance to, or extend in another specification, and that this is right level of granularity
kcoyle: community function
… see AP's as linked to communities (applications?)
… introduces idea of "consensus"
AndreaPerego: AP came out of validation requirement. RDFS did not support that so other documents were used
<antoine> karen would this capture what you said: "A profile can play a key role for a community to formalize expectations about the data that it cares about - and sharing these expectation with others."
AndreaPerego: 'minimal level of interoperability' - formal validation and compliance came later
<Zakim> LarsG, you wanted to talk about the DNB use cases
DaveBrowning: interplay between producers vs consumers
LarsG: Why I joined DXWG: DNB is large data publisher, need to tell consumers what it will look like
… BIBFrame for other libraries, dc+bibo+rda for metadata/rdf consumers
… want to use same URIs for different representations, hence profile negotiations
PWinstanley: profile description must be human-consumable
… levels of conformance should be supported
… machine-actionable validation and conformance-testing is secondary
… after 'guidance'
… look at f2f agenda: individual points refering to GitHub issues, how to proceed so we can get a draft of UP document
<antoine> +1
PWinstanley: need to build to FPWD so we can engage community
… how generalized? How specific? - get balance right so we can engage our constituency
<kcoyle> https://www.w3.org/2017/dxwg/wiki/F2f3#Agenda
https://github.com/w3c/dxwg/issues?q=is%3Aissue+is%3Aopen+label%3Af2f3
https://github.com/w3c/dxwg/milestone/8
<kcoyle> https://www.w3.org/2017/dxwg/wiki/F2f3#Agenda has the already approved requirements
Looking at Issues one by one
https://github.com/w3c/dxwg/issues/74
LarsG: this is about identification and negotiation
… probably reduced to 'must have an identifier' (so that negotiation is supported)
<antoine> I think we should keep 'profile'
<antoine> and replace 'content negotiation' by 'profile negotiation'
https://github.com/w3c/dxwg/issues/73
<antoine> I can do it
Action: antoine to fix labels
<trackbot> Created ACTION-109 - to fix labels [on Antoine Isaac - due 2018-05-15].
https://github.com/w3c/dxwg/issues/73 is not profile definition and semantics, is profile-negotiation
https://github.com/w3c/dxwg/issues/72 - keep
<kcoyle> https://github.com/w3c/dxwg/issues/69
More discussion about what is distinctive about 'profile' vs the more general 'specification or standard'
kcoyle: it is "constraining a more general base"
<Zakim> SimonCox, you wanted to (yetagain) ask if a 'profile' is a sub-class of 'specification' or 'standard'
SimonCox: The reqs in the list are probably not atomic enough.
<danbri> (I took another look at the SHACL and ShEx expression of DCAT-AP-ish constraints ... by converting a ShEx Schema.org/Dataset example to use DCAT. It nearly works, hope it will eventually make it easy to compare expressivity)
PWinstanley: This specific one (metadata guidance rule) is out of scope for our current discussion.
Jaroslav_Pullmann: What the intent of this document is, and how it relates to the others?
PWinstanley: We need to develop the skeleton of the profile definition deliverable.
… The google doc is meant to draft this.
… I would like to WG to work together now to mock it up.
Jaroslav_Pullmann: LarsG already drafted the HTML one.
<antoine> Lars' proposal: https://github.com/w3c/dxwg/issues/196
LarsG: Yes, I did it, but people were unhappy with it. So, better re-start from scratch.
antoine: [suggesting re-organisation of topics]
PWinstanley: I suggest we do this later. We need first to decide what's in and what's out.
<kcoyle> https://github.com/w3c/dxwg/issues/216
PWinstanley: Extending creating something new.
kcoyle: Extending may lead to go outside given bounds (e.g., DC and DCAT). Some people may want to define those bounds.
<antoine> if we are to discuss these issues quickly then my 2 cents on this issue is 'yes it's in scope' and at this stage we don't need to discuss a lot on extend vs refine. Its just 'based on' another profile by extension or refinement.
+1 to antoine
<riccardoAlbertoni> +1 to antoine
kcoyle: The main point here is that no new term is *defined* in the profile - extension means taking terms from existing vocabularies.
proposal: accept https://github.com/w3c/dxwg/issues/216
<kcoyle> +1
+1
<riccardoAlbertoni> +1
<antoine> +1
<alejandra> +1
Action: kcoyle find better wording for 216 especially "extend"
<trackbot> Created ACTION-110 - Find better wording for 216 especially "extend" [on Karen Coyle - due 2018-05-15].
<DaveBrowning> +1
all: [discussion on notions of extensions, refinement / restriction, and if this may lead to defining new terms]
LarsG: The creation of new terms could be delegated outside the profile.
<LarsG> +1
Resolved: accept https://github.com/w3c/dxwg/issues/216
Resolved: accept https://github.com/w3c/dxwg/issues/216
<riccardoAlbertoni> https://github.com/w3c/dxwg/issues/218
kcoyle: this is about listing the metadata terms to be used in the profile.
<antoine> +1 for 218 in scope maybe we can replace 'valid' by 'expected'?
kcoyle: +1 to antoine
proposal: accept https://github.com/w3c/dxwg/issues/218
<Zakim> tom_baker, you wanted to ask whether it is required to enumerate terms
tom_baker: there are 2 ways to specify terms - including constructs like super/sub-properties. So, we may not need to enumerate explicitly all terms to be used.
<antoine> @tom_baker: I've tried to capture what you say at https://github.com/w3c/dxwg/issues/218#issuecomment-387355632 is it ok?
Jaroslav_Pullmann: We would need concrete guidance on this.
antoine: about the previous issue - can I update the title in GH as agreed?
kcoyle: Please do.
PWinstanley: Should we move this down to validation?
Jaroslav_Pullmann: How this fits with the idea of having multiple profiles?
PWinstanley: We move this issue down - not "approved" for the time being.
https://github.com/w3c/dxwg/issues/220
kcoyle: It's about the constraint that profiles cannot define their terms, but just reuse terms from other vocabularies.
antoine:
… If we accept the notion of extension we can also accept that we can define new terms.
Jaroslav_Pullmann: Profile for me is not the schema - i.e., the XML Schema
… It does not have the purpose of a schema language.
LarsG: Probably we need to go back to what we mean with "extend".
… For me extending is extending what others have done, not adding something new.
… If I need to have my new terms, I have to define them elsewhere.
<danbri-osx> There are profiles that only make sense for RDF-like languages (we're in shex/shacl territory); there are those that work for all namespaces regardless of what kind of ns it is (we're in RDDL territory); there are those that are basically ontologies of document formats (in which case we revisit the forgotten https://www.w3.org/TR/NOTE-dcd ) ... and then there are those (which it seems is current focus) that have a "slightly more than RDF" notion of me[CUT]
antoine: Just to note that the issue title is uncontentious - should we discuss the details?
<antoine> I vote for including new terms
<danbri-osx> (latter sense is the merge of RDF-ish metadata plus http://dublincore.org/documents/abstract-model/ for noncommital, other senses of simple metadata, plus SKOS value spaces)
proposal: accept https://github.com/w3c/dxwg/issues/220
<antoine> if it stays in, it needs clarification, notably on the 'SHOULD'. Now 220 is worded as a 'MUST'
<antoine> I mean the wording of the first comment
LarsG: about the use of MUST / SHOULD, should we refer to RFC for what we mean?
proposal: accept https://github.com/w3c/dxwg/issues/220
+1
<PWinstanley> +1
<kcoyle> +1
<DaveBrowning> +1
<alejandra> +1
<LarsG> +1
<Jaroslav_Pullmann> +1
<riccardoAlbertoni> +1
<antoine> I'm waitign for Karen's comment :-)
<kcoyle> This is 'should' because there will be profiles done in environments that do not have the ability to create vocabulary terms in an external environment, or do not use IRIs for terms.
<antoine> ok +1 in the light of Karen's comment
Resolved: accept https://github.com/w3c/dxwg/issues/220
https://github.com/w3c/dxwg/issues/221
PWinstanley: This is about support to data creation functions.
AndreaPerego: Can we put a "may"/"might"?
DaveBrowning: "may"
<antoine> I'm going to do it
<antoine> done
Resolved: accept https://github.com/w3c/dxwg/issues/221
https://github.com/w3c/dxwg/issues/209
PWinstanley: It's about properties in profiles to link to at least 2 different levels of documentation.
<antoine> I don't understand what would be point 2 for this issue anyway...
all: [discussion on must/may]
SimonCox: It should be "may"
kcoyle: we should try to rephrase it.
<antoine> I am suggesting the should in the light of the Linked Data recipes: a LD URI should give something for humans, and profiles have URIs :-)
<antoine> happy with PWinstanley 's suggestion
PWinstanley: Do we agree we accept it, and that kcoyle will re-write it for us?
+1
<kcoyle> I'll look at the best practices work; maybe that will give me some wording
<riccardoAlbertoni> +1 to antoine's proposal
Action: kcoyle to find a new wording for https://github.com/w3c/dxwg/issues/209
<trackbot> Created ACTION-111 - Find a new wording for https://github.com/w3c/dxwg/issues/209 [on Karen Coyle - due 2018-05-15].
PWinstanley: We are talking here about the fact that profiles needs to be well documented, that may support data creation functions, that may or may be not extending existing specifications/standards/etc.
PWinstanley: So we need to be able to see that in the profile def document.
Jaroslav_Pullmann: We have not discussed thoroughly #209
… E.g., what about discoverability of profiles?
<antoine> discoverability is in another issue
<antoine> +1 to karen
SimonCox: It's still unclear to me how a profile is different from a schema/specification/standard.
PWinstanley: We know this is one of the topics we are going to discuss on.
<riccardoAlbertoni> quokka
[lunch]
<kcoyle> until 1:20, when we'll try to force folks back, but 1:30 isn't a bad guess
<kcoyle> we're coming back
<Jaroslav_Pullmann> welcome back, starting again
starting with: https://github.com/w3c/dxwg/issues/204
PWinstanley: there is only few background on the requirement on github
antoine: profiles can have an expression conforming to an schema/validation langauge
<kcoyle> https://www.w3.org/TR/dcat-ucr/#ID48
PWinstanley: should the profile refer to the validation framework/tooling?
SimonCox: referring to former profile definition: complies to one of the profile roles: validate resources
<riccardoAlbertoni> https://github.com/w3c/dxwg/tree/gh-pages/profiledesc/examples#dcat-ap
SimonCox: provides an example (package of cosntraints in SHACL)
<Zakim> AndreaPerego, you wanted to mention the ADMS approach to this - https://www.w3.org/TR/vocab-adms/
AndreaPerego: there are many similarities with ADMS
AndreaPerego: remember the old XML-days of DCAT-AP
SimonCox: there are different types of "validation" checking..
SimonCox: Contraints consider the format (media type), further constraints (SHACL) and a role they play
Resolved: accept https://github.com/w3c/dxwg/issues/204
<antoine> I think I prefer the way it is put in 204
<antoine> +1 for merging
<AndreaPerego> +1 from me as well
<alejandra> ok for me, as long as the two points are clear - one refers to the existence of the validation and the other one about the relationship with the profile, right?
proposal is to merge issues 208, 210 and 215 related to explicit validation constraints
riccardoAlbertoni: suggesting to be more explicit about the validation purpose (profile should define validation expression)
DaveBrowning: and mention the consequence in case the profile does not (will not be able to be used with validation services)
proposed: merge issues 208, 210 and 215 into a single issue
<AndreaPerego> +1
<PWinstanley> +1
<riccardoAlbertoni> +1
<DaveBrowning> +1
<LarsG> +1
<SimonCox> +1
<alejandra> +1
<kcoyle> +1
Resolved: accept merge issues 208, 210 and 215 into a single issue
now at item 5: Application profiles should provide constraint information sufficient to validate instance data.
antoine: is not this requirement already covered by the above (duplicate)?
kcoyle: documentation is a part of the profile to make it used/applied correctly
antoine: req. still needs clarification (purpose of the views)
AndreaPerego: which type of validation do we consider - machine or a manual one?
PWinstanley: profiles validation info should support both
LarsG: the different views might support dif. stages of the provcess
Resolved: accept https://github.com/w3c/dxwg/issues/211
PWinstanley: what is a search engine?
<kcoyle> https://w3c.github.io/dxwg/ucr/#ID40
apparently the requirement is misplaced and should move to discoverability, conneg or profile definition
kcoyle: relates to profile content
PWinstanley: does it apply exclusively to profiles (or other type of resources as well)?
<AndreaPerego> IMO, this is more about "how to publish" profile definitions.
danbri: same (search) technology could be applied as for other dcat resources
antoine: the profile might help linking to compliant dataset
<antoine> +0
PWinstanley: should we accept https://github.com/w3c/dxwg/issues/222 moving it into the profile content?
Resolved: remove 222 from the validation section, decide later
antoine: supporting leaving the req. within the validation section
<PWinstanley> Jaroslav_Pullmann: we had the discussion before about closed/open
<PWinstanley> ... what does it mean?
kcoyle: stems from the RDF design, are additional terms o.k.?
kcoyle: the librarian way of metadata treatment: restrictive, permissions/extensions needs to be explict
<antoine> how about "In this specification, we leave it open whether the expression of a profile in a data validation language should allow data elements to exist in the data which are not mentioned in the profile (open-world) or if such elements are disallowed (closed-world). This decision is left to profile owners."
proposed: accept 219 with the additional annotation (suggested by antoine)
<kcoyle> +1
<riccardoAlbertoni> +1
<DaveBrowning> +1
<antoine> +1
+1
moving towards section on "Relationships between profiles"
mistake, still at validation
PWinstanley and kcoyle discussing the precise wording extracted from the requirements
<antoine> I think this is clear enough for writing.
done with validation
now moving towards section on "Relationships between profiles"
antoine: supports reuse of validation resources/fragments
kcoyle: unclear what "easily publishable" and "optimized for re-use" means
alejandra: publishing of profiles should be easy / equivalent to DCAT datasets
<antoine> alejandra++ for example applying Best practices from the LD community or others.
AndreaPerego: supporting Alejandra's proposal for easy publication
AndreaPerego: the re-use of validation resources very much depends on the type of resources (o.k. for linked data, hard for douments)
LarsG: this relates to https://github.com/w3c/dxwg/issues/212 (profile inheritance)
DaveBrowning: what does in fact mean "optimized re-use"?
<PWinstanley> https://github.com/w3c/dxwg/issues/75
PWinstanley: pointing to the complex topic of the profile representation
Resolved: close issue https://github.com/w3c/dxwg/issues/75 since handled by other requirements
<PWinstanley> proposed: to take second section (after 'and') of issue 206 and move to issue 212
<riccardoAlbertoni> +1
<LarsG> +1
<DaveBrowning> +1
<PWinstanley> +1
AndreaPerego: is there a chance of re-use for non-machine readable specifications?
Resolved: to take second section (after 'and') of issue 206 and move to issue 212
LarsG: there is no need for restricting 206 to "machine readable" specs
LarsG: what do we mean by "publishable"?
<antoine> If PWinstanley is saying that #206 can be closed because it is redundant with #207 and #214 I think I agree
PWinstanley: relates much to relations among profiles - ensuring a validity of a composite profile
Resolved: close https://github.com/w3c/dxwg/issues/206
<antoine> what is common across profiles = what is reused from one profile into another
riccardoAlbertoni: unclear what "common parts" means
kcoyle: common parts are implicit when e.g. using same identifiers
PWinstanley: what is the matter of knowing when e.g. country codes / profile resources where reused?
DaveBrowning: possible interpretation: building a (profile) hierarchy
PWinstanley: e.g. to be able reflecting changes in underlying resources
PWinstanley: why would one like to know about the relationship among profiles?
jumping to https://github.com/w3c/dxwg/issues/214 without a resolution on 207
kcoyle: what does inhehrit mean?
LarsG: profile inheritance is already a practice, see national versions of DCAT-AP
<antoine> LarsG++
antoine: inheritance ensuring re-use of elements/constraints
<antoine> I'm fine with 'borrowing' too! :-)
PWinstanley: not having inheritance causes troubles in management, but inheritance might include unexpected contents
kcoyle: profiles would express their dependency
LarsG: dependency ~ inclusion
PWinstanley: there are multiple ways of implementing such relationship
<antoine> Some discussion on derivation/inheritance/re-use has happened at https://github.com/w3c/dxwg/issues/216
<alejandra> also note that inheritance in validation languages is still under discussion: https://github.com/shexSpec/shex/issues/50
AndreaPerego: confusion about the level of profile we are talking about - to which possible profile distribution would inheritance apply?
kcoyle: it is too early, profiles still not elaborated enough
<antoine> I agree with kcoyle we can't say much, but we shouldn't shy away from being clear about what we consider to be best practices
PWinstanley: there might already exist technology specifc solution (XML import)
alejandra: inheritance is important, but validation languages may not support it
<PWinstanley> Jaroslav_Pullmann: we need to talk about inheritance resilution rules
<PWinstanley> ...ODRL are making thoughts about resolving contradictory rules
danbri-mob: who were the end users of such profiles i.e. become users of the inheritance mechanism
PWinstanley: there is interest at least in the applicatiton profile community
SimonCox: re-use and inheritance are relevant to cope with the extent / manageability
PWinstanley: organizations might be interested because of efficiency reasons
<antoine> +1 for stating it as best practice
AndreaPerego: all the topic is about modularity and governance (support)
<danbri> -1, heavy derivative relationships will need security reviews and so on, versioning etc; I wouldn't go beyond literature/landscape review and case studies at this stage.
<kcoyle> proposed: accept #212
<kcoyle> +1
<antoine> +1
<AndreaPerego> +1
<alejandra> +1
<PWinstanley> +1
<DaveBrowning> +1
+0 wondering how this best practice should be followed, when there is no concensus on "inheritance"..?
<alejandra> I thought we are voting to accept the issue, as a way of recording that we are including a comment about inheritance in the best practice document
<alejandra> not that we are resolving the inheritance issue
<antoine> +1
.. we then should ensure we provide an indication what st should be (inheritance = import etc.?)
<kcoyle> +1 Alejandra - we aren't resolving the issue
Resolved: accept #212
<danbri> (-1 -> 0 if this is just collecting case studies; there is no best practice yet)
break, back in 15 minutes
https://github.com/w3c/dxwg/issues/214
kcoyle: this is also dependant on the inheritance technique
<antoine> Anyway I don't have much to say: it seems that in light of the discussion on 212 we should close 214
antoine: Seems 214 is a specific (more complex) case of 212
<alejandra> +1 to Antoine's comment
antoine: if we can't make a recomendation for 212 then can we do for 214
danbri: advertising this kind of thing would be useful, but do we know anyone?
<antoine> s/a recommendation/a technical recommendation
AndreaPerego: INSPIRE has been in this space, but not full actionable inheritance
danbri: Perhaps in an axiomatic way
kcoyle: do we even take it on?
Jaroslav_Pullmann: Don't leave it completely blank in terms of requirements (e.g. that if someone uses inheritance, then they need to do this conformance support)
kcoyle: but we don't any anything to offer
LarsG: if its just guidance then we don't need to be categorical, we can help form/guide around what we see as the key elements
SimonCox: Bits of OGC etc are also sharing bits of schema across deliverables
<PWinstanley> https://iptc.org/standards/sportsml-g2/ might be instructive about sharing components across applications
SimonCox: UML doesn't have global identifiers so its a bit of a problem
kcoyle: About 214 - would this be more palatable if this said 'should' not must?
… what would be useful is to explain (explicitly) what the relationship between the profiles is
… anytime a profile specialises another one
LarsG: we can't say anything about mechanisms here, since we're only covering guidance
… it would depend on the technology
kcoyle: But we do want a description of the conformance 'commitment' for each inherited profile
LarsG: But what guidance could we give?
antoine: we do have a profile description ontology
<antoine> I am thhinking a rule of the form "X conformsTo specificProfile inheritsFrom genericProfile => X conformsTo genericProfile"
SimonCox: Though is is (deliberately) lightweight since its cross-technology
<SimonCox> https://w3c.github.io/dxwg/profiledesc/profiledesc.html
<antoine> I think that even if it's lightweight it would allow that sort of axiom to be stated.
SimonCox: examples (which explain its working) https://github.com/w3c/dxwg/tree/gh-pages/profiledesc/examples
kcoyle: what is described in rob/nick work is a description of the application profile and its context, not how you do it
SimonCox: An rdf example would be a good addition to the examples
AndreaPerego: Similar issues/approaches for most formal mechanisms like UML
antoine: We not planning on saying how to do validation rules
<AndreaPerego> s/approaches were addressed in ADMS, also for more/approaches for most/
<antoine> https://docs.google.com/drawings/d/1dHkpwKwUwMgS1RqSCTPO3uOoRiY_qNk0z5bhXJlYi4Y/
SimonCox: (After discussion of DCAT-AP example) Some slight errors in current picture but they aren't key to the topic today
kcoyle: Interesting in how this picture fits with the Rob/Nick picture?
SimonCox: Very similar - some minor differences/missing but they can be added
… (ie role)
… otherwise pretty much aligned
<antoine> I think the role idea is promising - I just missed the time to read it thoroughly.
kcoyle: Back to 214 - if re-written, is it appropriate for guidance doc?
LarsG: We should make clear people doing profile inheritance need to be explicit on conformance commitment
PWinstanley: In some cases (data governance) then potentially verification is going to be needed
<kcoyle> proposed: accept 214 as re-worded by Simon
<kcoyle> If conformance to a profile is claimed, then it should be possible to confirm conformance to each parent profile
<LarsG> +1
<Jaroslav_Pullmann> +1
<antoine> +1
<SimonCox> +1
+1
<AndreaPerego> +1
<alejandra> +1
<riccardoAlbertoni> +1
<PWinstanley> +1
<danbri> +1
Resolved: accept 214 as re-worded by Simon
<antoine> why was 205 in the part on relationship between profiles?
https://github.com/w3c/dxwg/issues/205
kcoyle: Already agreed that they should have public identifiers
<danbri> suggest maybe "Profiles are Web documents and as such are identified in the normal way [webarch link]. Many profiles will be public and typically resolvable; some may be private in various ways e.g. used in B2B or within large organizations."
<Zakim> danbri, you wanted to discuss public vs not
proposed: accept 205 with minor editing
<antoine> (for the minutes) In fact the requirement dates from the time we hadn't agreed that profiles should have public identifiers
<AndreaPerego> +1
<kcoyle> +1
<danbri> https://www.w3.org/TR/webarch/#identification
<PWinstanley> +1
<danbri> +1
<antoine> +1
+1
<LarsG> +1
<riccardoAlbertoni> +1
<alejandra> +1
Resolved: accept 205
<antoine> does anyone know what "a view that includes" would be?
kcoyle: Isn't this redundant?
<antoine> maybe this is redundant with https://github.com//dxwg/issues/207 ?
kcoyle: we already said they should have a human view as well as machine
antoine: perhaps not out of scope, but not very important
<danbri> 213 sounds like standardizing user interface
proposed: Declare 213 as out of scope
<kcoyle> +1
<danbri> +1
<PWinstanley> +1
+1
<AndreaPerego> +1
<riccardoAlbertoni> +1
<alejandra> +1
<Jaroslav_Pullmann> 0
<LarsG> 0
<antoine> 0 I don't agree it's out of scope but I agree closing it
<antoine> this ticket doesn't say how a view should look like, it just says that anyone willing to go into such eandeavour should be able to need the data they find.
Jaroslav_Pullmann: we might want to leave it in the ucr as a desirable feature but not say anything in the actual guidance
<danbri> If every profile's URL could have JSONP JSON-LD data in meta.json well known URL then a pure Javascript application could recurse back and find all parent metadata. Given browser constraints around x-site fetching, this is the simplest hack I can think of that would allow profiles to evolve loosly coupled.
LarsG: Looking at 207 - part of that should go up the the previous section, leaving the relationship part in this section
kcoyle: Important that we say what information is needed but not how its made available
Resolved: Declare 213 out of scope but look to restructure the overall set of requirements tomorrow
kcoyle: Tomorrow we can look at the different levels of profile use
<AndreaPerego> [meeting adjourned]
Succeeded: s/people/who is
Succeeded: s/scribenick LarsG/scribenick: LarsG/
Succeeded: s/kcoyle thanks Riccardo for organising the meeting/kcoyle: thanks Riccardo for organising the meeting/
Succeeded: s/scribe LarsG/scribe: LarsG/
Succeeded: s/RIDDL/GRDDL/
Succeeded: s/GRDDL/RDDL/
Succeeded: s/addresses/accomplish/
Succeeded: s/scribenick SimonCox//
Succeeded: s/mutimedia/multimedia/
Succeeded: s/suppor/support/
Succeeded: s/no term is *defined*/no new term is *defined* in the profile/
Succeeded: s/valid terms/metadata terms/
Succeeded: s/clarification/first comment
Succeeded: s/+!/+1/
Succeeded: s/to be well documents/to be well documented/
Succeeded: s/224/221/
Succeeded: s/on the validation/of the validation
Succeeded: s/doe snot/does not/
Succeeded: s/proviles /profiles /
Succeeded: s/help linked/help linking/
Succeeded: s/should data/should allow data
Succeeded: s/propsoed/proposed/
Succeeded: s/this clear/this is clear/
Succeeded: s/prior/other
Succeeded: s/whay/why/
Succeeded: s/contens/contents/
Succeeded: s/bebcause/because/
Succeeded: s/mitght /might /
Failed: s/a recommendation/a technical recommendation
Succeeded: s/describle/described/
Failed: s/approaches were addressed in ADMS, also for more/approaches for most/
Succeeded: s/find/need