Hello,
I'm reacting to Stefanie's mail as I was the one raising the fact that some requirements were difficult to understand.
Requirements I think I understand
-----------------------------------------------
R-1-UNIQUENESS-OF-URIS :-) +1
In my opinion it says that the the validation process must be able to
check wether all URIs are unique.
R-68-REQUIRED-PROPERTIES :-) +1
I think this means that the validation process must be able to check
wether all properties, that are mandatory for the description of an
instance of a class, exist. E.g. the use of the property edm:type is
mandatory describing instances of the class edm:ProvidedCHO
R-28-Object-PROPERTY-RANGE :-) +1
I think it means that the validation process must be able to check
wether the value used as an object of a triple is an instance of a class
that is allowed to be used in the range of the property of the triple.
E.g. ex:myBirthday edm:occuredAt ex:myTelefon is not valid because the
range of edm:occuredAt ist edm:TimeSpan and my telefon is not an
instance of the class edm:TimeSpan.
-->I would suggest to remove the abbreviations used in the definition of the requirements such as OPE, CE. They relate to other requirements that are not part of the DC categories and that are also quite difficult to understand (at least for me)
I like your definition for this requirement Stefanie. Maybe we could add it in the database? In fact it would be easier for me to understand the requirements if they were formulated in this style even if it is a bit more verbose than the current description.
R-72-RECOMMENDED-PROPERTIES :-) +1
I guess this means that the validation process must be able to check
wether properties, that are recommended for the descripion of an
instance of a class, exist. But there is no description or definition of
this requirement, so I can only guess.
R-45-Literal-Value-Range :-) +1
Means that the validation process must check wether the value used as an
object of a triple makes sense.
Requirements I don't understand
----------------------------------------------
R-25-OBJECT-PROPERTY-DOMAIN and R-26-DATA-PROPERTY-DOMAIN :-( + 1
I'm not realley sure I understand this right. In my opinion the
requirements say that the validation process must be able to check
wether the value used as an subject of a triple is an instance of a
class that can be used with the property of the triple. E.g. ex:myTable
edm:begin ex:20thCentury is not valid because the edm specification says
that edm:begin can only be used to describe instances of the class
edm:Agent or the class edm:TimeSpan and my table is neither an agent nor
a time span. But ex:myNiece edm:begin "1995" is valid, because my niece
is an edm:Agent.
So if this requirements demand the validation of the domain, I need only
one requirement and if not, what does they mean?
R-76-MAXIMUM-QUALIFIED-CARDINALITY-RESTRICTION and
R-78-MINIMUM-QUALIFIED-CARDINALITY-RESTRICTION :-( +1
I guess it means that the validation process must be able to check
wether the occurence of properties describing an instance of a class
correspond to the allowed occurence of this property describing one
instance. I think R-76 talks about the repeatability of the property but
I'm not sure where the difference is between R-68-REQUIRED-PROPERTIES
and R-78-MINIMUM-QUALIFIED-CARDINALITY-RESTRICTION. And I can only guess
what they mean because as in R-72 a definition or description is missing.
R-46-CONSTRAINING-FACETS and R-35-DATA-PROPERTY-RANGE :-(
I don't understand the difference between these two requirements. Both
say that it is necessary to check the literal value that is an object of
the triple. Or not?
---> Most of these requirements are difficult to understand because they don't have a definition. I think we should make it mandatory to have always a description for requirements to avoid confusion.
I also noticed that R-47 Language Tag Matching is formulated as a question. If we are not sure about the validity of a requirement, if might be better to discuss it on the list and then formalise it in the database.
Best,
Valentine
Am 04.09.2014 05:15, schrieb Karen Coyle:
> Can be found at:
>
> http://wiki.dublincore.org/index.php/RDF-Application-Profiles/minutes20140902
>
>
> The action items from the meeting are:
>
> ACTION: Karen to Finalize outline and send Stuart a description of
> what our audience should come away with.
> ACTION: Stefanie to send on the list 5 reqs she understands, and 5
> that she doesn't.
> ACTION: chairs to ask on mailing list for shepherds for other cases
> ACTION: Antoine to send an email to the list suggesting to record
> example in constraint languages in the database.
> ACTION: Antoine to create constraints for two easy examples and two
> hard ones, from Stefanie's list.
> ACTION: Kai to develop a template for deliverables. - Goal: keep it
> short :)
>
> kc
--
Stefanie Rühle
Metadata and Data Conversion
Georg-August-Universität Göttingen
Göttingen State and University Library
D-37070 Göttingen
Papendiek 14 (Historical Building, room 1.603)
+49 551 39-10905 (Tel.)
[log in to unmask]
|