search

HughP / simal

Automatically exported from code.google.com/p/simal
0 stars 0 forks source link

Validate submitted RDF against DOAP and FOAF spec - (Badly specified people not visible) #403

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I know you're sick of hearing "bad RDF creates bad output" :) But: if you have 
an RDF like this:

...
<Developer>
<foaf:person>
...
</foaf:person>
</Developer>
...

The person gets saved, but isn't visible anywhere - including in the person 
browser. You can tell they're saved because you can't save another record with 
the same email address.

(Note the incorrect capitalisation of "Developer" in the example.)

Original issue reported on code.google.com by Stevage on 7 Mar 2011 at 1:54

GoogleCodeExporter commented 9 years ago 
There is a known issue where the DOAPCreator widget is producing none DOAP RDF 
and the UI is not able to represent it. There has been a fair amount of 
discussion and a solution proposed, see issue 314

However, I'm not sure you are reporting the same problem here. You point out 
the capitalisation of "Developer". How was this RDF created?

Original comment by ross.gardler on 7 Mar 2011 at 4:23

GoogleCodeExporter commented 9 years ago 
>How was this RDF created?

By a bug in my RDF. I didn't realise for a while that there is *no validation* 
of imported RDF anywhere. That's really the core issue here, I think. There are 
quite a few ways RDF can get into Simal, and they all need to check it for 
correctness, and reject it if necessary.

Original comment by Stevage on 10 Mar 2011 at 12:38

GoogleCodeExporter commented 9 years ago 
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. ;)

Original comment by sander.v...@oucs.ox.ac.uk on 11 Mar 2011 at 1:24

GoogleCodeExporter commented 9 years ago 
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.

Original comment by ross.gardler on 11 Mar 2011 at 7:37

GoogleCodeExporter commented 9 years ago 
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...")

Original comment by Stevage on 14 Mar 2011 at 1:03