This is related to #1106484: Provide overview of all mappings for all bundles.

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.

CommentFileSizeAuthor
#4 1106662_semweb-pane.png67.82 KBscor
#1 1106662-rdf-configuration-section.patch2.22 KBlinclark

Comments

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Needs review
StatusFileSize
new 1106662-rdf-configuration-section.patch2.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.

scor’s picture

scor commented

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.)

Anonymous’s picture

Anonymous (not verified) commented

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?

scor’s picture

scor commented
StatusFileSize
new 1106662_semweb-pane.png67.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:

1106662_semweb-pane.png

Anonymous’s picture

Anonymous (not verified) commented

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.

scor’s picture

scor commented

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.

Anonymous’s picture

Anonymous (not verified) commented

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

milesw’s picture

milesw commented

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.

Anonymous’s picture

Anonymous (not verified) commented

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?

scor’s picture

scor commented
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.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

milesw’s picture

milesw commented
Project: Resource Description Framework (RDF) » RDF Extensions