Re: AW: Requirements for profiles

I dont think we can expect any profile language to be completely expressive
- formal constraints may be expressed for a subset of the constraints in a
profile, and a subclass of profiles are completely expressed by
constraints...

we just need good enough model of how constraint expressions relate to
profiles.



On Thu, 11 Jan 2018 at 20:06 Antoine Isaac <aisaac@few.vu.nl> wrote:

> Very interesting discussion, Karen and Lars. Which mad me think a bit, do
> we want a requirement for making a complete list of features that  profile
> languages (both for humans and machine) could/should handle? And trying to
> align the profile languages? This would be very hard. We know that
> different languages will focus on different things, some quite
> irreconcilable (think of expressing constraints on the order of elements in
> RDF...)
>
> Cheers,
>
> Antoine
>
> On 11/01/18 02:02, Karen Coyle wrote:
> >
> >
> > On 1/10/18 10:46 AM, Svensson, Lars wrote:
> >> Karen,
> >>
> >> On Monday, December 11, 2017 2:10 PM, Karen Coyle [mailto:
> kcoyle@kcoyle.net] wrote:
> >>
> >>> Lars, I've been looking at DSP and ShEx. Something that is missing from
> >>> DSP is any ability to define relationships between elements. This is
> the
> >>> bulk, however, of what SHACL and ShEx provide. So a simple ShEx
> statement:
> >>>
> >>> my:UserShape {
> >>>    (
> >>>       foaf:name LITERAL
> >>>
> >>>      |
> >>>        foaf:givenName LITERAL+;
> >>>        foaf:familyName LITERAL
> >>>    );
> >>>    foaf:mbox IRI
> >>> }
> >>>
> >>> which includes: "either a foaf:name OR (a foaf:givenName AND a
> >>> foaf:familyName)"
> >>>
> >>> is not something that either the DSP nor the tables of CSVW can
> express.
> >>> And that is one of the simpler cases that SHACL and ShEx are designed
> to
> >>> handle.
> >>
> >> Do you think it could be possible to extend DSP to accomodate those
> kinds of patterns?
> >
> > The sum of patterns is pretty complex. I did a brief "patterns" document
> > [1] to summarize it. As I understand it, this also goes beyond OWL in
> > terms of complexity, but these are exactly the cases that ShEx and SHACL
> > deal with.
> >
> >>
> >>> One solution could be to use either SHACL or ShEx to express profiles.
> >>
> >> Focusing exclusively on SHACL and ShEx seems a bit too RDF-centric to
> me.
> >
> > I think that if one were to focus on design patterns, the "RDF-ness"
> > would be less imposing.
> >
> >>
> >>> The down side of that is the human-readability/creatability factor,
> >>> since both of these are complex executable code that are good at the
> >>> detail of a profile but are hard to read for the macro data structure
> >>> (which DSP aims at). If we can at least bridge the gap that would turn
> >>> either of those into documentation that people can be comfortable with,
> >>> that would take us quite a ways.
> >>
> >> That said, I think that it should be possible to create a
> human-readable page from a well-documented SHACL or ShEx document just as
> you can create HTML from an RDF vocabulary document (by evaluating
> rdf:label, dc:comment etc. in the class and property descriptions). I guess
> that best practices will emerge here.
> >
> > Where I think SHACL and ShEx are limited is in their focus on individual
> > graphs. I have yet to see a document that gives a good overview of a
> > profile in SHACL or ShEx. So I would be interested in someone pursuing
> > this as an option.
> >
> > kc
> >
> > [1] https://github.com/kcoyle/RDF-AP/blob/master/Patterns.md
> >
> >>
> >> Best,
> >>
> >> Lars
> >>
> >>> On 12/11/17 3:17 AM, Svensson, Lars wrote:
> >>>> Hi Karen,
> >>>>
> >>>> On Mittwoch, 22. November 2017 02:10, Karen Coyle [mailto:
> kcoyle@kcoyle.net]
> >>> wrote:
> >>>>
> >>>> [...]
> >>>>
> >>>>> * I once again would like folks to look at the technology stack of
> the Singapore
> >>> Framework [1] which may be compatible with
> >>>>> the statement that a "profile defines a set of additional structural
> and constraints
> >>> and/or semantic interpretations that can
> >>>>> apply to a given document on top of that document's media type." If
> the
> >>> Framework doesn't have the same sense as the quote,
> >>>>> perhaps we can clarify the differences. And eventually I would like
> to talk about
> >>> the concept of description sets [2] which is the
> >>>>> DCMI view of profiles.
> >>>>
> >>>> Even if it's not the same, at least there is significant overlap with
> my view of
> >>> profiles. The DSP document states that a "DSP is a way of describing
> structural
> >>> constraints on a description set. It constrains the resources that may
> be described by
> >>> descriptions in the description set, the properties that may be used,
> and the ways a
> >>> value surrogate may be given" which is close enough (although it
> mainly speaks of
> >>> properties and less of classes).
> >>>>
> >>>> Also the Singapore Framework goes in the right direction even if I
> think it's too RDFy
> >>> in that it mandates that "all references to terms in a Dublin Core
> metadata description
> >>> be made using URIs" (what about XML QNames?) and that it only talks
> about metadata
> >>> records where our scope is any kind of data.
> >>>>
> >>>> As an aside, it's interesting to note that the DSP document itself
> defines a profile for
> >>> a DSP (ยง6) that is formalized in an XML schema; the creation of a ShEx
> document
> >>> shouldn't be difficult and is left as an exercise for the reader.
> >>>>
> >>>>> [1] http://dublincore.org/documents/singapore-framework/
> >>>>> And this is a shortcut to the diagram, which may be the most useful
> >>>>> part:
> >>>>>
> http://dublincore.org/documents/2008/01/14/singapore-framework/singapore-
> >>> framework.png
> >>>>> [2] http://dublincore.org/documents/dc-dsp/ however some of the
> details pre-date
> >>> general acceptance of RDF and need to change,
> >>>>> so don't get hung up on how the lower levels of the model are defined
> >>>>
> >>>> Best,
> >>>>
> >>>> Lars
> >>>>
> >>>> On 11/21/17 4:26 PM, Rob Atkinson wrote:
> >>>>>
> >>>>> Profiles should IMHO reference type ontologies where necessary to
> >>>>> further restrict the range of profiled properties (either base
> >>>>> specification or a more general profile).
> >>>>>
> >>>>> e.g. a profile for "spatial area statistics standard X" may require
> >>>>> the statistical dimension property  is related to (has a rdfs:range)
> >>>>> a 'feature with a polygon geometry' ,
> >>>>>
> >>>>> the "US Census profile" may require this to have a FIPS code and the
> >>>>> 2020 census may require it to be from the set of 2020 US  state
> >>>>> boundaries, by reference to a specific implementation.
> >>>>>
> >>>>> I think "vocabulary" is a set of definitions in the general case, and
> >>>>> is agnostic about how much information model goes along with that set
> >>>>> - so we need to be pretty careful about assumptions as to what it
> means here.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, 22 Nov 2017 at 10:21 Karen Coyle <kcoyle@kcoyle.net
> >>>>> <mailto:kcoyle@kcoyle.net>> wrote:
> >>>>>
> >>>>>      Are you referring to value vocabularies? I was thinking about
> >>>>>      properties, and in the profiles I've seen they tend to be lists
> of terms
> >>>>>      representing properties and classes.
> >>>>>
> >>>>>      kc
> >>>>>
> >>>>>      On 11/21/17 2:18 PM, Rob Atkinson wrote:
> >>>>>      >
> >>>>>      > Profiles should reference controlled vocabularies - and
> practically
> >>>>>      > these must be accessible via distributions such as REST API
> >>>>>      endpoints -
> >>>>>      >  - consider GBIF biota taxon vocabulary - miilons of terms
> and changes
> >>>>>      > every day. Can not embed this in a profile, or even in a
> static
> >>>>>      resource.
> >>>>>      >
> >>>>>      > Rob
> >>>>>      >
> >>>>>      >
> >>>>>      >
> >>>>>      > On Wed, 22 Nov 2017 at 09:11 Karen Coyle <kcoyle@kcoyle.net
> >>>>>      <mailto:kcoyle@kcoyle.net>
> >>>>>      > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> wrote:
> >>>>>      >
> >>>>>      >
> >>>>>      >
> >>>>>      >     On 11/21/17 12:25 PM, Antoine Isaac wrote:
> >>>>>      >     > Hi Karen,
> >>>>>      >     >
> >>>>>      >     > I'm trying to work on it.
> >>>>>      >     > But I have to say I'm a bit lost, what has happened to
> our
> >>>>>      use case
> >>>>>      >     > (5.37) and requirements. At some point everything was
> >>>>>      included at
> >>>>>      >     > https://w3c.github.io/dxwg/ucr/#ID37
> >>>>>      >     > but the requirement list seems to have been really
> >>>>>      simplified, not the
> >>>>>      >     > only requirement derived from 5.37 is
> >>>>>      >     > https://w3c.github.io/dxwg/ucr/#RID11
> >>>>>      >     >
> >>>>>      >     > When we contributed our use case we had listed these
> >>>>>      requirements:
> >>>>>      >     > - Each application profile needs to be documented,
> preferably by
> >>>>>      >     > showing/reusing what is common across profiles
> >>>>>      >
> >>>>>      >     We'll make sure that these get in. I do have a very basic
> >>>>>      question,
> >>>>>      >     though, which is whether you have any assumptions about
> the
> >>>>>      content of a
> >>>>>      >     profile. This says that it is documented, that it is
> >>>>>      machine-readable,
> >>>>>      >     that it contains validation, and that profiles can contain
> >>>>>      pieces of
> >>>>>      >     data from other profiles. Is there some statement that
> can be
> >>>>>      made about
> >>>>>      >     the nature of this data? Are you assuming that profiles
> contain
> >>>>>      >     vocabulary terms? This seems to be the missing background
> >>>>>      information
> >>>>>      >     from our requirements.
> >>>>>      >
> >>>>>      >     kc
> >>>>>      >
> >>>>>      >     > - Machine-readable specifications of application
> profiles
> >>>>>      need to be
> >>>>>      >     > easily publishable, and optimize re-use of existing
> >>>>>      specification.
> >>>>>      >     > - Application profiles need a rich expression for the
> the
> >>>>>      >     validation of
> >>>>>      >     > metadata
> >>>>>      >     > - publishers (data providers, intermediary aggregators,
> >>>>>      Europeana and
> >>>>>      >     > DPLA) need to be able to indicate the profile to which a
> >>>>>      certain piece
> >>>>>      >     > of data (record describing an individual cultural
> object, or
> >>>>>      a whole
> >>>>>      >     > dataset) belong.
> >>>>>      >     > - Data publishers need to be able to serve different
> >>>>>      profiles of the
> >>>>>      >     > same data via the same data publication channel (Web
> API)
> >>>>>      >     > - Data consumers (intermediary aggregators, Europeana
> and
> >>>>>      DPLA, data
> >>>>>      >     > consumers) need to be able to specify the profile they
> are
> >>>>>      >     interested in
> >>>>>      >     > - Europeana needs to be able to accept the data
> described
> >>>>>      using EDM
> >>>>>      >     > extensions that are compatible with its EDM-external
> profile
> >>>>>      >     whether it
> >>>>>      >     > doesn't ingest this data entirely (i.e. some elements
> will
> >>>>>      be left out
> >>>>>      >     > are they are useless for the main Europeana Collections
> >>>>>      portal) or it
> >>>>>      >     > does ingest it (e.g. for Thematic Collections portals or
> >>>>>      >     domain-specific
> >>>>>      >     > applications that Europeana or third parties would
> develop)
> >>>>>      >     >
> >>>>>      >     > I'm going to see how it aligns to your list. But I
> prefered to
> >>>>>      >     send you
> >>>>>      >     > our raw list now, so that you can have a brief look at.
> If just
> >>>>>      >     because
> >>>>>      >     > this list supports your point " Also, there are some
> obvious
> >>>>>      >     > requirements, like being both machine and
> human-readable, having
> >>>>>      >     > identifiers, etc., that we do not have use cases for".
> >>>>>      Valentine and I
> >>>>>      >     > wanted our use case to be a motivation for such
> requirements...
> >>>>>      >     >
> >>>>>      >     > Cheers,
> >>>>>      >     >
> >>>>>      >     > Antoine
> >>>>>      >     >
> >>>>>      >     > On 21/11/17 16:34, Karen Coyle wrote:
> >>>>>      >     >> Because we need to move to FPWD, if we can agree on the
> >>>>>      >     requirements for
> >>>>>      >     >> profiles as written here, we can amend those for the
> next
> >>>>>      >     publication of
> >>>>>      >     >> the UCR. We can add a note that these are still in
> flux.
> >>>>>      >     >>
> >>>>>      >     >> kc
> >>>>>      >     >>
> >>>>>      >     >> On 11/20/17 1:57 PM, Antoine Isaac wrote:
> >>>>>      >     >>> Hi Karen, all,
> >>>>>      >     >>>
> >>>>>      >     >>> Sorry I wanted to do this today but I will probably
> won't
> >>>>>      have time,
> >>>>>      >     >>> also seeing that a considerable thread has appeared
> after your
> >>>>>      >     initial
> >>>>>      >     >>> email and will probably require reading...
> >>>>>      >     >>> I'll try to do this week, though reorganization at
> >>>>>      Europeana is
> >>>>>      >     keeping
> >>>>>      >     >>> me busy.
> >>>>>      >     >>>
> >>>>>      >     >>> Very likely regrets for tomorrow by the way :-/
> >>>>>      >     >>>
> >>>>>      >     >>> Antoine
> >>>>>      >     >>>
> >>>>>      >     >>> On 15/11/17 04:32, Karen Coyle wrote:
> >>>>>      >     >>>> All, I'm not sure that this requirement list is
> complete
> >>>>>      but it
> >>>>>      >     is what
> >>>>>      >     >>>> I could come up with in a short time so that we
> could have
> >>>>>      >     something to
> >>>>>      >     >>>> discuss. [Note to Antoine and Valentine: please see
> if I
> >>>>>      correctly
> >>>>>      >     >>>> captured the requirements from your use case.]
> >>>>>      >     >>>>
> >>>>>      >     >>>> I want to mention that I believe there may be more
> than one
> >>>>>      >     definition
> >>>>>      >     >>>> of "profile" being used in the use cases. In
> particular,
> >>>>>      UC 5.3
> >>>>>      >     >>>> (submitted by Ruben) didn't seem to me to be a
> function of
> >>>>>      >     profiles but
> >>>>>      >     >>>> of the connection service. There may be other such
> >>>>>      differences
> >>>>>      >     in the
> >>>>>      >     >>>> use cases where I'm not sure if the reference is to
> the
> >>>>>      profile
> >>>>>      >     or to a
> >>>>>      >     >>>> specific selection of instance data.
> >>>>>      >     >>>>
> >>>>>      >     >>>> Also, there are some obvious requirements, like
> being both
> >>>>>      >     machine and
> >>>>>      >     >>>> human-readable, having identifiers, etc., that we do
> not have
> >>>>>      >     use cases
> >>>>>      >     >>>> for. I did a talk at the recent Dublin Core
> conference that
> >>>>>      >     included a
> >>>>>      >     >>>> number of requirements of this nature that we may
> wish to
> >>>>>      examine.
> >>>>>      >     >>>>
> >>>>>      >     >>>>
> >>>>>
> http://dcevents.dublincore.org/IntConf/dc-2017/paper/view/520/643
> >>>>>      >     >>>>
> >>>>>      >     >>>>
> >>>>>      >     >>>> ****
> >>>>>      >     >>>> profiles list valid vocabulary terms for a metadata
> usage
> >>>>>      >     environment
> >>>>>      >     >>>> (5.37)
> >>>>>      >     >>>>
> >>>>>      >     >>>> profile vocabulary lists may be defined as closed
> (no other
> >>>>>      >     terms are
> >>>>>      >     >>>> allowed) or open (other terms are allowed) (5.37)
> >>>>>      >     >>>>
> >>>>>      >     >>>> conceptually, profiles can extend other vocabularies
> or
> >>>>>      >     profiles, or
> >>>>>      >     >>>> can
> >>>>>      >     >>>> be refinements of other vocabularies or profiles
> (5.37)
> >>>>>      >     >>>>
> >>>>>      >     >>>> profiles can be "cascading", inheriting from other
> >>>>>      profiles or
> >>>>>      >     profile
> >>>>>      >     >>>> fragments (discussion at first f2f)
> >>>>>      >     >>>>
> >>>>>      >     >>>> profiles reuse vocabulary terms defined elsewhere
> (Dublin
> >>>>>      Core
> >>>>>      >     >>>> profiles;
> >>>>>      >     >>>> no use case)
> >>>>>      >     >>>>
> >>>>>      >     >>>> profiles must be able to define finer-grained
> semantics for
> >>>>>      >     vocabulary
> >>>>>      >     >>>> terms that are used (visible in DCAT APs)
> >>>>>      >     >>>>
> >>>>>      >     >>>> profiles must be able to express rules that support
> data
> >>>>>      validation
> >>>>>      >     >>>> (cardinality, valid values) (5.41)
> >>>>>      >     >>>>
> >>>>>      >     >>>> profiles must be able to express cardinality rules of
> >>>>>      >     vocabulary terms
> >>>>>      >     >>>> (5.41)
> >>>>>      >     >>>>
> >>>>>      >     >>>> profiles can contain links to detailed validation
> rules or to
> >>>>>      >     >>>> validation
> >>>>>      >     >>>> applications that can process the profile (5.48)
> >>>>>      >     >>>>
> >>>>>      >     >>>> profiles must be able to support information that can
> >>>>>      drive data
> >>>>>      >     >>>> creation functions, including brief and detailed
> >>>>>      documentation
> >>>>>      >     (5.46)
> >>>>>      >     >>>>
> >>>>>      >     >>>> profiles must be able to express what standards
> >>>>>      (including creation
> >>>>>      >     >>>> rules) the data conforms to (5.43) (5.42)
> >>>>>      >     >>>>
> >>>>>      >     >>>> profiles must support discoverability via search
> engines
> >>>>>      (5.40)
> >>>>>      >     >>>>
> >>>>>      >     >>>> profiles must have identifiers that can be used to
> link
> >>>>>      the DCAT
> >>>>>      >     >>>> description to the relevant profile (seems obvious;
> no
> >>>>>      use case)
> >>>>>      >     >>>>
> >>>>>      >     >>>> *Not covered* (because I didn't know what the
> requirement
> >>>>>      would
> >>>>>      >     be):
> >>>>>      >     >>>> 5.3
> >>>>>      >     >>>> Responses can conform to multiple, modular profiles
> (by
> >>>>>      Ruben)
> >>>>>      >     >>>>
> >>>>>      >     >>>> kc
> >>>>>      >     >>>>
> >>>>>      >     >>>
> >>>>>      >     >>
> >>>>>      >     >
> >>>>>      >
> >>>>>      >     --
> >>>>>      >     Karen Coyle
> >>>>>      >     kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>
> >>>>>      <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>
> http://kcoyle.net
> >>>>>      >     m: 1-510-435-8234 (Signal)
> >>>>>      >     skype: kcoylenet/+1-510-984-3600 <+1%20510-984-3600>
> <tel:+1%20510-984-3600>
> >>>>>      <tel:+1%20510-984-3600>
> >>>>>      >
> >>>>>
> >>>>>      --
> >>>>>      Karen Coyle
> >>>>>      kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
> >>>>>      m: 1-510-435-8234 (Signal)
> >>>>>      skype: kcoylenet/+1-510-984-3600 <+1%20510-984-3600>
> <tel:+1%20510-984-3600>
> >>>>>
> >>>>
> >>>> --
> >>>> Karen Coyle
> >>>> kcoyle@kcoyle.net http://kcoyle.net
> >>>> m: 1-510-435-8234 (Signal)
> >>>> skype: kcoylenet/+1-510-984-3600 <+1%20510-984-3600>
> >>>>
> >>>
> >>> --
> >>> Karen Coyle
> >>> kcoyle@kcoyle.net http://kcoyle.net
> >>> m: 1-510-435-8234 (Signal)
> >>> skype: kcoylenet/+1-510-984-3600 <+1%20510-984-3600>
> >>
> >
>
>

Received on Thursday, 11 January 2018 09:36:01 UTC