Hi Thomas,
This makes me think about a potential feature to consider for the database. Can we had something to distinguish between the requirements that are originated from the DC task group work from the ones discussed on the W3C list?
I know that the link between cases and requirements allow us to find the list of "Dublin Core" requirements. But there is no shortcut to get requirements that are connected to all DC cases, in one go. [1]
Why am I asking this? Honestly, I find that what is happening on the W3C list is really good to stimulate people around the creation of the work. But from a design process perspective, it's a real nightmare. All these emails are fired with no grounding on real cases (I'm not saying they're not legit, just that there is no explicit relation with real cases).
I'd like our work in the task group not to be polluted by this. If you can entertain the noise, that's great. But I don't have the time, and I suppose many people on the DC task group won't have either.
Besides, if the W3C group starts, the requirements will probably be tracked through a W3C issue system. And those issues will probably be quite strictly controlled, i.e. only approved requirements connected to use cases will be kept there. I would regard this as a good practice for us too.
Again, I'm not requesting that you wouldn't introduce the W3C list requirements in your DB. You created it, it would be unfair for us to dictate its use. What I'd like is that at any moment we can say 'ok, this is our curated data, and this is the explorative stuff from others'. If we can't do it, I'm afraid the DB won't be usable by the group.
Cheers,
Antoine
[1] I believe there must be a way to get a requirement listing it quite easily.
What I'm wondering is whether this can be applied to the facets on the left menu. I believe these need to work on the entire requirement database.
On 7/27/14 10:31 AM, Bosch, Thomas wrote:
> Hi Simon,
>
> I added this requirement to the RDF validation requirements db:
> http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=R-190-SPECIFY-EXPECTED-BEHAVIOR-UNDER-ALL-POSSIBLE-ENTAILMENT-REGIMES
>
>
> Kind regards,
> Thomas
>
> --
>
> Thomas Bosch, M.Sc. (TUM)
>
> PhD Student
>
> GESIS - Leibniz Institute for the Social Sciences
>
> Social Science Metadata Standards
>
> Visitors Address: B2,1, D-68159 Mannheim
>
> Postal Address: P.O.Box 12 21 55, D-68072 Mannheim
>
> Tel: + 49 (0) 621 / 1246-271
>
> Fax: + 49 (0) 621 / 1246-100
>
> Web: http://www.gesis.org
>
> Website: http://boschthomas.blogspot.com/
> GitHub: _https://github.com/boschthomas/PhD_
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *Von:* Simon Spero [[log in to unmask]]
> *Gesendet:* Freitag, 25. Juli 2014 22:43
> *An:* Kendall Clark
> *Cc:* [log in to unmask]
> *Betreff:* Re: OWL is hard?
>
> On Fri, Jul 25, 2014 at 1:46 PM, Kendall Clark <[log in to unmask] <mailto:[log in to unmask]>> wrote:
>
>
> foaf:Person class,
> foaf:name 1 1,
> foo:email 1 1,
> foo:phone 0 * .
>
> Some Manchester syntax (again corrections welcome)
>
> Class: foaf:[P]erson
> foaf:name exactly 1
> foo:email exactly 1
> foo:phone min 0
>
>
> I'm not sure exactly what constraint is being specified on on foo:phone in the original example.
>
> The informal description is about a web service which requires that "all resources submitted to it must be of type foaf:Person, must have a foaf:name and a foo:email, and possibly one or more foo:phone".
>
> a) If the intended meaning of the final clause is that the cardinality of foo:phone is between 0 and infinity, then it is trivial.
>
> b) If the intended meaning of the final clause is to serve purely as documentation then it is not really a constraint.
>
> c) If the intended meaning of the entire phrase is that it is to be construed using /expressio unius <http://en.wikipedia.org/wiki/Statutory_interpretation#Textual>/, then the final clause /is/ necessary, because any predicates not explicitly mentioned are forbidden. Under this interpretation,
>
> Example 1 is valid:
> 1)
>
> [ a foaf:Person ;
>
> foaf:name "John F. Manning" ;
>
> foo:email "[log in to unmask] <mailto:[log in to unmask]>";
> ].
>
> But:
>
> *2)
>
> [ a foaf:Person,foaf:Agent ;
>
> foaf:name "John F. Manning" ;
>
> foo:email "mailto:[log in to unmask] <mailto:[log in to unmask]>";
> ].
>
> ... is invalid, because it includes a value for rdf:type even though that value is entailed by the foaf Ontology.
> A similar problem could occur if there were sub or super-properties of foo:email - e.g. if there were sub properties for officialEmail and personalEmail, or if there were a super property contactURL.
>
> Also:
> *3)
>
> [ a foaf:Person ;
>
> foaf:name "John F. Manning" ;
>
> foo:email "[log in to unmask] <mailto:[log in to unmask]>";
>
> foaf:gender "male";
>
> ].
>
> ... is invalid, because foaf:gender is not explicitly mentioned.
>
> Any specification that implements this approach must specify expected behavior under all possible entailment regimes.
>
> I am not sure if it is possible to specify in OWL the constraint that the maximum cardinality for all properties apart from a specifically mentioned set is 0 (it is probably doable in SPARQL as long as entailment regimes are handled carefully).
>
> It would not be too hard to define OWL constructs that could serve this purpose if the CWA is in effect- e.g. pseudo-properties like 'otherObjectProperties' and 'otherDataProperties', or even 'otherProperties'. This kind of pseudo-property would probably not be suitable for use in inferencing.
>
> Simon
|