Re: Some DC requirements

On 12/11/2014 07:24 AM, Karen Coyle wrote:
> Below are some requirements from DC that may differ somewhat from the stories
> already in the wiki. I do see some overlap, but the stories themselves are
> different. (If someone could add these to the wiki, I'd be grateful. We're
> still having problems with wiki permissions for DC.)
>
> I may have others but I'm posting this now because we are in the midst of a
> rain and wind storm that means that power is fragile, and it's just occurred
> to me that DSL modems really *should* have a battery backup, but do not.
>
> ******
>
> Mandatory & Repeatable
> by Karen Coyle
> Folks in our community are used to cardinality being expressed as "mandatory
> or optional" and "repeatable or not-repeatable". We don't have any use cases
> for a more open-ended min/maxCardinality, so we wish to include these in our
> core requirements, with their "min/max" being defined in a layer that the
> requirements user does not see.

I'm guessing that these correspond to [0,1], [1,1], [1,*], and [0,*], but it 
would be nice to get some confirmation of this.

> Checking the IRIs
> by Karen Coyle
> Europeana aggregates metadata about cultural heritage objects from hundreds of
> libraries, archives and museums. The incoming data needs to be thoroughly
> checked for accuracy. Among these checks are those on IRIs as values, which
> can vary depending on the property. Briefly, the checks are
> 1) the IRI must resolve, i.e. http status code = 2XX
> 2) the IRI value must return a media object of a given type (e.g. based on
> list of MIME types)
> 3) the IRI value must return an object which is of the rdf:type SKOS:Concept

I am uncomfortable including this kind of checking, although I do see that it 
has uses.  One issue here is that the results of the checks are all ephemeral.

> Comparing values
> by Karen Coyle
> There are cases where the values in two or more triples have a specific
> relationship. The obvious one is "birthDate/deathDate" or "startDate/endDate".
> The validation model must allow these to be defined. One assumption is that
> the validation takes place within the context of a graph or node. Another is
> that the comparison is between literal values or datatypes, not IRIs. The
> question of whether this could be used more generally for ordering of lists is
> still being discussed, but it may be best to treat lists as a special case.

I believe that there already is a story about relationships between literal 
values of properties.

> Defining allowed values
> by Karen Coyle
> Developers need to have these ways of defining the allowed values for each
> property
> 1) must be an IRI
> 2) must be an IRI matching this pattern (e.g.
> http://id.loc.gov/authorities/names/)
> 3) must be an IRI matching one of these patterns
> 4) must be a (any) literal
> 5) must be one of these literals ("red" "blue" "green")
> 6) must be a typed literal of this type (e.g. XML dataType)

I believe that all (or at least almost all) of these are already in some story 
or other.

peter

Received on Thursday, 11 December 2014 16:10:57 UTC