Comment #3 on issue 403 by sander.v...@oucs.ox.ac.uk: Validate submitted
RDF against DOAP and FOAF spec - (Badly specified people not visible)
http://code.google.com/p/simal/issues/detail?id=403
You raise an interesting issue. I agree that there should be some level of
validation, but the power of RDF lies partly in the fact that it's
extensible. Hence, it is also a *good* thing that you can include include
triples in your RDF that relate to an ontology Simal has never encountered.
Aside, your example mentions lowercase foaf:person, which should be
foaf:Person. As a general rule of thumb, properties are all lowercase
whereas classes are capitalised.
I agree that some level of validation is required, but we need to find the
middle ground here. For example, only check the RDF on correct triples for
the simal, DOAP and FOAF ontologies.
Note, however, that Simal itself is a bit sloppy. I only recently found out
that doap:shortname, that we use quite extensively, is actually not part of
the doap spec. ;)
Comment #4 on issue 403 by ross.gardler: Validate submitted RDF against
DOAP and FOAF spec - (Badly specified people not visible)
http://code.google.com/p/simal/issues/detail?id=403
For me, as we have discussed in the passed, validation against known
problems is a good idea (i.e. empty descriptions), also I'm in total
agreement with Steve that if we have code to generate and insert DOAP it
should only be adding RDF that is handled gracefully by Simal. Entering
people on the form and then not seeing them in the UI is bad. As noted
above this is already covered in issue 314, so should not be the topic in
this issue. Having proper validation will help stop us introducing such
bugs.
With respect to the validation against DOAP and FOAF specs may already be
covered by Issue 165. I'm therefore merging these two issues.
Sander: I would describe the "middle ground" like this:
1) If data in an imported RDF will be safely ignored by Simal, it can be
passed by the validator.
2) If missing data in an imported RDF will cause problems in Simal, the
import should be blocked.
Currently, various bits of code assume the existence of different fields
(like project description) - these should be documented, and enforced.
In addition, some of these assumptions should be changed. For example, I
don't see that a project description *should* be mandatory. For some
deployments, a name is sufficient to be meaningful.
(Btw, if it's not clear, "should" above means, "IMHO in an ideal world with
infinite coding monkeys, I think what I'm proposing is better than the
current situation, but am happy to be persuaded otherwise...")