Provide all RDF configuration options in one section in Configuration [#1106662]

We want to have a few different configuration pages, such as creating namespace mapping definitions and a bundle mapping overview. It makes a lot of sense to present these together in the configurations section.

Comment	File	Size	Author
#4	1106662_semweb-pane.png	67.82 KB	scor
#1	1106662-rdf-configuration-section.patch	2.22 KB	linclark

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Anonymous (not verified) CreditAttribution: Anonymous commented 27 March 2011 at 17:58

Status:

Active

» Needs review

File	Size
1106662-rdf-configuration-section.patch	2.22 KB

This adds an RDF section to the Web Services box on the configuration page. While RDF is not a Web Service, neither is RSS and it is so closely related to RSS that it makes sense to group them.

It defines two pages, one for overviewing mappings and another for overviewing namespaces. Neither have yet been implemented.

Comment #2

scor CreditAttribution: scor commented 30 March 2011 at 13:07

Where do we draw the line between "structure" and "configuration"? These are the elements we have to fit somewhere in the admin area:
- RDF settings such as default RDF serialization output (which we don't have yet)
- RDF namespaces management (CRUD UI)
- RDF mapping UI (currently in content types and wherever Field UI is)
- RDF mappings overview
- SPARQL Endpoints Registry
- SPARQL Views resource types

I know RDFx does not care about sparql or sparql_view, but it would be good to get the whole RDF picture and see where these RDF related modules admin pages will fit.

how about this?

structure
-- RDF mapping UI (currently in content types and wherever Field UI is)
-- SPARQL Views resource types
configuration
-- RDF settings
-- RDF namespaces management (CRUD UI)
-- RDF mappings overview
-- SPARQL Endpoints Registry

I've left SPARQL Views resource types in structure because it is closely related to Views, which is placed in Structure.
Note that if the RDF mappings overview is just a listing, it should probably live in "Reports" next to Field list (Overview of fields on all entity types.)

Comment #3

Anonymous (not verified) CreditAttribution: Anonymous commented 30 March 2011 at 13:25

I agree with keeping SPARQL Views resources in the structure section section, because it's also closely tied (in the user interaction) with content types.

I'm thinking that SPARQL could have it's own listing in Configuration, just to keep things modular, but that it would also be in the Services section. So that would be:

Services
-- RDF publishing
---- RDF mappings overview
---- RDF namespaces management (CRUD UI)
-- RSS (from core)
-- SPARQL data integration
---- SPARQL Endpoints Registry

I would prefer to keep "RDF mappings overview" and "RDF namespaces management" grouped together rather than placing different parts of RDF configuration in different configuration sections. I think most people don't understand RDF at all, so giving them a menu of the things they can do will help them understand what the RDF capabilities of Drupal are.

I'm not totally set on RDF and SPARQL being separate sections and not totally set on them being under Services either. What do you think on those two issues?

Comment #4

scor CreditAttribution: scor commented 4 April 2011 at 15:33

File	Size
1106662_semweb-pane.png	67.82 KB

I'm thinking that the bottom level item such as RDF namespaces and RDF mappings won't be so visible. Also, if you check the other items from the admin configuration page, the vast majority don't have tabs inside them. Wouldn't it make sense to add a new pane in the configuration page for "Semantic Web" with the following items in it:

Comment #5

Anonymous (not verified) CreditAttribution: Anonymous commented 4 April 2011 at 15:40

It makes sense to have them all in the box instead of having tabs.

How about a title like Data Interoperability? Even in spite of how much it has been pushed in the Drupal community, Semantic Web is still meaningless to most people. I think Data Interoperability describes the features of the modules rather than the general research topic.

Comment #6

scor CreditAttribution: scor commented 4 April 2011 at 15:54

yes, Data Interoperability sounds very good, and could even be used by non rdf modules, so we're not introducing anything too rdf specific here. Not sure what the best practice here is in term of what category names to use, but we can always tune that later if we find other modules use, once we have some equivalent of this http://groups.drupal.org/node/97054 for config categories.

Let's settle on data interoperability for now, so we can move on with this issue.

Comment #7

Anonymous (not verified) CreditAttribution: Anonymous commented 4 April 2011 at 15:58

Sounds good, I can post a new patch later tonight (if I have Internet, first thing tomorrow morning if not).

Comment #8

milesw CreditAttribution: milesw commented 6 April 2011 at 16:36

Data Interoperability is quite good. I'm wondering if it could be just a little friendlier - "Data Sharing" maybe?

However, it seems the original IA intended all these items to fall under Web Services: http://drupal.org/node/557792

Also, I think the groupings in #3 work well and leave room for expansion. Tabs aren't so evil. And I think people would appreciate less items showing up on the Configuration page.

Comment #9

Anonymous (not verified) CreditAttribution: Anonymous commented 6 April 2011 at 21:10

Woah, nice archival access skills, milesw... I never even saw that thread.

Hmmmm... I have to say, I actually like the wording that we ended up with, I think Data Interoperability describes the function much better than Web Services.... but I do think it really belongs in the same place as RSS and RESTful Services. Stéph, any opinions between the two?

Comment #10

scor CreditAttribution: scor commented 7 April 2011 at 02:45

Status:

Needs review

» Fixed

Let's stick with Web Services. We seem to all agree that the structure in #3 (partially implemented in the patch #1) is the way to go: I've committed the patch in #1 so we can move on in the other issues.