* Bosch, Thomas <[log in to unmask]> [2015-01-06 14:59+0000]
> Hi,
>
> yes, as we have use cases for matching shapes and for class assignments (rdf:type) we should definitely offer both validation entry points.
> And this is easy implementable in SPIN.
>
> Best,
> Thomas
>
>
> Thanks, Thomas, for this analysis. The one thing that I think we will
> need to add is the ability to define constraints in relation to rdf:type
> declarations. For example, in EDM, there is a rule that for each
> edm:ProvidedCHO there must be one ore:Aggregation. Then the required
> properties are within the context of ProvidedCHO and Aggregation. I
> think that the DSP description template serves this function, but is not
> based around an rdf:type. Making that a type-based unit shouldn't be too
> difficult. The current rules for applying DSPs (in section 3 of the
> document) make the connection between the DSP and the graph based on the
> pattern of the statements. This has problems because missing statements,
> or added statements, can cause a graph not to match the pattern in the
> DSP. There are cases where matching on patterns is fine, but others
> require a type.
Just to see if I understand the motivations and reactions here, is it
the case that you are adding type arcs to your instance data because
some SPIN strategies require them? I know that it will not be possible
for me to add type arcs match all of the shapes that clinical data may
match so I've been pushing back very hard against requiring types to
initiate validation. Is that underlying assumption different in your
use cases?
> kc
>
> On 1/6/15 2:50 AM, Bosch, Thomas wrote:
> > Hi,
> >
> > I also think it is worth to have a DSP core covering the majority of our use cases.
> > The new DSP can be mapped to whatever the W3C develops as language.
> >
> > I made a quick evaluation of BIBFRAME regarding our mentioned requirements:
> >
> > simple cardinality is covered by BIBFRAME:
> >
> > "propertyTemplate": [
> > { ... },
> > {
> > "propertyURI": "http://bibframe.org/vocab/titleStatement",
> > "propertyLabel": "Title",
> > "mandatory": "true",
> > "repeatable": "true",
> > "type": "literal"
> > },
> > { ... }
> > ]
> >
> > allowed values are not covered by BIBFRAME
> > allowedValues may be introduced for valueConstraints as follows:
> >
> > "propertyTemplates": [
> > { ... },
> > {
> > "propertyURI": "http://bibframe.org/vocab/subject",
> > "propertyLabel": "Subject",
> > "type": "resource",
> > "valueConstraint": {
> > "allowedValues": [ "value 1","value 2","value 3" ]
> > }
> > },
> > { ... }
> > ]
> >
> > valid datatypes may be covered by BIBFRAME as this is an implementation issue.
> > You can state constraints on datatypes for literals in BIBFRAME:
> >
> > "propertyTemplates": [
> > { ... },
> > {
> > "propertyURI": "http://bibframe.org/vocab/vra/beginDate",
> > "propertyLabel": "Begin Date",
> > "type": "literal",
> > "valueConstraint": {
> > "valueDataType": {
> > "dataTypeURI": "http://bibframe.org/vocab/proposed/ISO8601",
> > "dataTypeLabel": "ISO 8601",
> > "dataTypeLabelHint": "ISO"
> > }
> > }
> > },
> > { ... }
> > ]
> >
> > What is needed here is to implement to check for each datatype if the literal is valid.
> > Regular expressions may be used here in the background when SPARQL is used for the actual implementation.
> >
> > property/class grouping (e.g. propertyX is used for classY) is covered by BIBFRAME, as property templates are referenced within resource templates:
> >
> > "resourceTemplate": [
> > {
> > "id": "bfp:Work:Book",
> > "resourceLabel": "Book",
> > "resourceURI": "http://bibframe.org/vocab/Text",
> > "propertyTemplates": [
> > { ... }
> > ]
> > }
> >
> >
> > Cheers,
> > Thomas
> >
> >
> > So as not to take up time on the call tomorrow, and also to reach a
> > wider group, here is my update on the W3C work:
> >
> > W3C has also been on hiatus during the holidays, but the meetings resume
> > on Thursday. They meet weekly. There will also be a face-to-face meeting
> > mid-February in Boston. (I will be there.)
> >
> > My guess as to what will transpire over the next months (and it is a
> > guess) is that W3C will develop a fairly technical, detailed spec for
> > validation. Because it will be technical and detailed, this is going to
> > take some time. They will probably not address a user interface for the
> > validation, although there are some members of the group for whom this
> > is a priority. I suspect that will be offered outside of the W3C process
> > by some.
> >
> > I think that we can assume that the details of the rules for validation
> > will be covered by W3C. I also think that we can assume that the spec
> > will be more detailed than what our community generally needs. This
> > means that there could be room for the development of a user view to a
> > core of requirements. In my opinion, a lot could be accomplished with
> > just a few requirements:
> >
> > - simple cardinality (mandatory/optional, repeatable/not-)
> > - value checking (allowed values, valid data-types)
> > - property/class grouping (e.g. propertyX is used for classY)
> >
> > The DSP covers this and more. We might want to consider a "DSP-core"
> > that hides some of the "more". I think it's worth looking at the
> > BIBFRAME profiles [1].
> >
> > Something the DSP doesn't do but that will be prominent in the W3C work
> > is tying validation to rdf:type declarations. DSP has resourceClass but
> > not as a focus for validation. I think we should look at that.
> >
> > kc
> > [1] http://www.loc.gov/bibframe/docs/bibframe-profiles.html
> >
> >
> > --
> > Karen Coyle
> > [log in to unmask] http://kcoyle.net
> > m: 1-510-435-8234
> > skype: kcoylenet/+1-510-984-3600
> >
>
> --
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet/+1-510-984-3600
--
-ericP
office: +1.617.599.3509
mobile: +33.6.80.80.35.59
([log in to unmask])
Feel free to forward this message to any list for any purpose other than
email address distribution.
There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
|