For weeks now I've assumed the autocomplete inputs on the mapping forms were broken because I never once saw results. I wasn't even sure where results were supposed to come from - within the site or from external sources. Today, after seeing results appear for the datatype input, I decided to dig into the module code.

The reason I was getting no results is because I haven't loaded any data into the rdfx database tables. Now that I've enabled evoc and imported all the core vocabularies, I see how the autocomplete is supposed to work.

For the predicates and type inputs, I'm thinking it would be nice to return all predicates and types currently used throughout the site. It may be unlikely someone would want to reuse these, but at least it becomes clear what the autocomplete is intended for.

Thoughts?

Comments

Anonymous’s picture

Anonymous (not verified) commented

This is actually something that I have had in the back of my mind for a while. It is definitely broken right now since rdfui doesn't depend on evoc and I don't think we want to introduce a dependency on evoc. Instead, we should decouple the two. I think scor thinks the same (he may have even mentioned it in an issue.)

This way, if there were some kind of service that provided term lists (kind of like prefix.cc does for namespace prefixes), we could use that too. I'm guessing this could be a hook.

We could write some logic that would check to see if either evoc or anything else return anything from the hook. If not, then we could just pass in any terms currently used in the system, as you suggested.

milesw’s picture

milesw commented

Great idea, I can definitely imagine scenarios where you would want to query a service for these results.

Any thoughts on how we might handle terms from namespaces the site is not aware of? Right now rdfx, rdfui, and evoc all seem to heavily rely on the use of prefixes. In fact, the RDF UI mapping form should probably validate that the site is aware of the entered prefix/namespace, don't you think?

Anonymous’s picture

Anonymous (not verified) commented

Yes, I had this question in the back of my mind myself.

We could check at validation and not allow them to save terms that have an un-registered namespace. Or, we could just use drupal_set_message on form submission to say which prefixes were not registered and give a link to the namespace mapping interface.

scor’s picture

scor commented
Title: RDF UI: usage of autocomplete inputs is confusing » Make the RDF UI autocomplete more extensible

yes, I thought I had an issue on that, but can't find it, so let this one be it!

I was thinking to call a hook to get the available terms from any module willing to provide them... so, for example:
1. evoc would provide the terms from the imported vocabulary
2. terms.cc (à la prefix.cc, TDB) which pulls them from an external service (and maybe cache them)
3. some custom module could provide a list of hard coded terms only useful (or allowed) for their site
4. another module could gather the existing mappings from the site (like milesw said in #0).

scor’s picture

scor commented
Project: Resource Description Framework (RDF) » RDF Extensions
Component: D7. RDF UI » User interface
milesw’s picture

milesw commented
Assigned: Unassigned » milesw

During the code sprint Skype call we discussed this a bit and trying an alter hook might make sense. I'll give it a first attempt and see what happens...

scor’s picture

scor commented

When I mentioned the alter hook, I meant to say that if that's what Lin had in the current implementation of the autocomplete, it was better to create a new hook. That's usually what modules do: they allow other modules to expose data (e.g hook_menu), and then run drupal_alter to give other modules a change to alter each others' data (hook_menu_alter).

milesw’s picture

milesw commented
Assigned: milesw » Unassigned

I have had zero time to work on this, so I'm unassigning for now.

Anonymous’s picture

Anonymous (not verified) commented

I think that miles had a patch that he was working on for this issue. Miles, would you mind posting that patch? We can take a look at whatever you have so far and move forward with that.

milesw’s picture

milesw commented

No I haven't been working on this issue. I was working on inline mapping forms for the mappings overview page. But then my laptop's logic board died and I haven't yet been able to recover that work.

Anonymous’s picture

Anonymous (not verified) commented

Oh no! so sorry to hear that! good luck getting the data migrated.