https://redmine.dataone.org/https://redmine.dataone.org/favicon.ico2013-07-18T22:39:58ZDataONE TasksInfrastructure - Task #3867: ORE parsing error: ore:describes elementhttps://redmine.dataone.org/issues/3867?journal_id=165222013-07-18T22:39:58ZSkye Roseboomsroseboo@dataone.unm.edu
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/diff/16522?detail_id=22828">diff</a>)</li></ul> Infrastructure - Task #3867: ORE parsing error: ore:describes elementhttps://redmine.dataone.org/issues/3867?journal_id=165332013-07-23T20:53:22ZRob Nahfrnahf@epscor.unm.edu
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>30</i></li></ul><p>The python foresite library doesn't have the same issue as the java foresite library. It treats object-literals that are valid URIs the same as it would things represented as rdf:resources. It seems to inherit this behavior from the python rdflib module, so it's not a conscious decision on its part.</p>
<p>The java version assumes it's getting an OREResource, and throws an exception when it tries to cast the literal as one. It seems to be overly strict.</p>
<p>The ORE user guide recommends using the rdf:resource syntax for URIs, but it's not a requirement. ( see ObjectRule under <a href="http://www.openarchives.org/ore/1.0/rdfxml#SummaryRDFXML">http://www.openarchives.org/ore/1.0/rdfxml#SummaryRDFXML</a>)</p>
<blockquote>
<p>"If the object of the triple is a URI reference, add an attribute with the QName rdf:resource and make the value of this attribute a URI reference corresponding to the object"</p>
</blockquote>
Infrastructure - Task #3867: ORE parsing error: ore:describes elementhttps://redmine.dataone.org/issues/3867?journal_id=165362013-07-24T21:42:28ZRob Nahfrnahf@epscor.unm.edu
<ul></ul><p>Dave pointed out that the reference RDF checker shows two disconnected sub-graphs when fed a Merritt resource map, which is contrary to ORE specifications. Since the main problem is with the indexer, updating the Merritt and ONEShare resource maps would obsolete and archive the existing ones that are causing problems, and bypass the problem.</p>
<p>Checking with Mark Reyes at Merritt to see if they are able to accomplish this. </p>
<p>Otherwise, we would need to resort to extending the Jena foresite implementation in d1_libclient_java, and override the behavior in that circumstance.</p>
Infrastructure - Task #3867: ORE parsing error: ore:describes elementhttps://redmine.dataone.org/issues/3867?journal_id=168942013-08-09T17:37:43ZRob Nahfrnahf@epscor.unm.edu
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Closed</i></li><li><strong>% Done</strong> changed from <i>30</i> to <i>100</i></li><li><strong>translation missing: en.field_remaining_hours</strong> set to <i>0.0</i></li></ul><p>these disconnected graphs should be considered as malformed resource maps. Merritt will create updates for their (and ONEShare's) bad maps.</p>