Task #3867

ORE parsing error: ore:describes element

Added by Skye Roseboom almost 11 years ago. Updated almost 11 years ago.

Target version:
Start date:
Due date:
% Done:


Product Version:
Story Points:


Testing foresite ORE document parsing on production member nodes discovered that ORE documents from Merritt and ONEShare MN raise errors in the foresite RDF/ORE parsing library.

The error is related to the ore:describes element as defined in ORE docs from these MN -- for example:

Line 36:

Seems to be missing the rdf:resource definition - for example:

Once this modification is made, foresite parsing seems happy.

Need to determine if this issue can be resolved in parsing or whether these documents are actually valid RDF/ORE.

Related issues

Related to Member Nodes - Task #3906: Update malformed Resource Maps New 2013-08-09


#1 Updated by Skye Roseboom almost 11 years ago

  • Description updated (diff)

#2 Updated by Rob Nahf almost 11 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 30

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.

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.

The ORE user guide recommends using the rdf:resource syntax for URIs, but it's not a requirement. ( see ObjectRule under

"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"

#3 Updated by Rob Nahf almost 11 years ago

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.

Checking with Mark Reyes at Merritt to see if they are able to accomplish this.

Otherwise, we would need to resort to extending the Jena foresite implementation in d1_libclient_java, and override the behavior in that circumstance.

#4 Updated by Rob Nahf almost 11 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 30 to 100
  • translation missing: en.field_remaining_hours set to 0.0

these disconnected graphs should be considered as malformed resource maps. Merritt will create updates for their (and ONEShare's) bad maps.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)