I'm writing a desktop app using Gnome technologies, and I reached the
stage I started planning Semantic Desktop support.
After a lot of brainstorming, sketching ideas and models, writing notes
and reading a lot about RDF and related topics, I finally came up with a
plan draft.
The first thing I decided to do is to define the way I give URIs to
resources, and this is where I'd like to hear your advice.
My program consists of two parts:
1) On the lower level, an RDF schema is defined. It's a standard set of
classes and properties, possible extended by users who want more options
(using a definition language translated to RDF).
2) On the high level, the user defines resources using those classes and
properties.
There's no problem with the lower level, because the data model is
public: Even if a user decides to add new content, she's very welcome to
share it and make other people's apps have more features. The problem is
with the second part. In the higher level, the user defines tasks,
meetings, appointments, plans and schedules. These may be private, and
the user may prefer to to have any info in the URI revealing the source
of the information.
So here are the questions I have on my mind:
1) Which URI scheme should I use? I don't have a website or any web
pages, so using http doesn't make sense. It also doesn't seem to make
sense to use any other standard IANA-registered URI. I've been
considering two options: Use some custom, my own, URI scheme name for
public resources, and use a bare URN for private ones, something like
this:
urn : random_name_i_made_up : some_private_resource_uuid
But I was wondering whether a custom URI scheme is a good decision, I'm
open to hear ideas from you :)
2) How to hide the private resources? On one hand, it may be very useful
for the URI to tell where a task came from, especially when tasks are
shared and delegated between people. On the other hand, it doesn't
consider privacy. Then I was thinking, can I/should I use two different
URI styles depending on user settings? This would create some
inconsistency. I'm not sure what to do here, since I don't have any
experience with URIs. Hopefully you have some advice for me.
1) Which URI scheme should I use?
I would advise the standard urn:uuid: followed by your resource UUID. Using standards is generally to be preferred over home-grown solutions!
2) How to hide the private resources?
Don't use different identifier schemes. Trying to bake authorization and access control into the identity scheme is mixing the layers in a way that's bound to cause you pain in the future. For example, what happens if a user makes some currently private content (e.g. a draft) into public (it's now in its publishable form)?
Have a single, uniform identifier solution, then provide one or more services that may or may not resolve a given identifier to a document, depending on context (user identity, metadata about the content itself, etc etc). Yes this is much like an HTTP server would do, so you may want to reconsider whether to have an embedded HTTP service in your architecture. If not, the service you need will have many similarities to HTTP, you just need to be clear the circumstances in which an identifier may be resolved to a document, what happens when that is either not possible or not permitted, etc.
You may also want to consider where you're going to add the most value. Re-inventing the basic service access protocols may be a fun exercise, but your users may get more value if you re-use standard components at the basic service level, and concentrate instead on innovating and adding features once the user actually has access to the content objects.
Related
I have an application that, for a specific resource at URI x, generates a system of URIs such as x#a, x#b and so on, and stores them in an RDF graph at any position in a triple, even as predicates.
This is fine but the issue arises when the resource that should be described in this way is provided "inline" i.e. without a URI. In RDF I have the option to use blank nodes, but there are two issues I have with them:
Blank nodes are mostly regarded with existential meaning, i.e. they denote some node. The nodes produced by the application are not just some nodes – they are exactly the nodes produced from one specific resource that was given to them at one specific time. In contrast, a blank node can be "satisfied" by a concrete URI node with the same relations to other nodes, becoming redundant in presence of such a node.
Blank nodes cannot be unfortunately used as predicates in RDF (or at least in some formatting schemes).
This means that I have to find a URI, but I am wondering what scheme to choose. So far I have considered these options:
Generate a new UUID and use urn:uuid:. This is sufficient, but I would prefer something that expresses the temporary status of the URI better, so that it would be apparent it was generated for this one case only. In comparison, UUIDs can be used as stable identifiers for more permanent resources as well, and there is no inherent distinction.
Use a proprietary URI, like nodeID: which is sometimes used for blank nodes, but is still a valid URI nonetheless. I would append a new UUID to that as well. This seems a bit better to me since it mimics blank nodes but without their different semantics, but I would still prefer something more standardized.
Use tag: URIs. Tags have a time component to them, so the temporal notion is expressed sufficiently. However, I am not sure about the authority since whoever runs the application will in essence become the authority. Another option is to use my own domain and somehow "grant" the rights of minting tags to anyone running the application (or just to anyone in general). This way, I can express everything I need (the temporary notion of the resource, the uniqueness since I would also include a new UUID in the URI, and a description of the purpose and use of the tags on the website itself).
This is in my opinion not a bad solution, but it somewhat limits the usage of the application, as once my control of the domain expires, users of the application will no longer have the rights to mint new tags under the original authority, and they will have to find a new one (unless I leave the authority blank; while it is not strictly stated by the specification, anything is technically valid since implementations must not reject non-conforming authorities). I am also concerned about the time component itself, as it might pose a security risk (although it can be less specific). I am also not overly accustomed to the concept of tags, so I am not sure if it isn't against their spirit.
I can provide all of these methods as options in the application, but I would like to know if there are perhaps better options.
I want to generate a very short Unique ID, in my web app, that can be used to handle sessions. Sessions, as in users connecting to eachother's session, with this ID.
But how can I keep track of these IDs? Basically, I want to generate a short ID, check if it is already in use, and create a new if it is.
Could I simply have a static class, that has a collection of these IDs? Are there other smarter, better ways to do this?
I would like to avoid using a database for this, if possible.
Generally, static variables, apart from the places may be declared, will stay alive during application lifetime. An application lifetime ended after processing the last request and a specific time (configurable in web.config) as idle. As a result, you can define your variable to store Short-IDS whenever you are convenient.
However, there are a number of tools and well-known third-parties which are candidate to choose. MemCache is one of the major facilities which deserve your notice as it is been used widely in giant applications such as Facebook and others.
Based on how you want to arrange your software architecture you may prefer your own written facilities or use third-parties. Most considerable advantage of the third-parties is the fact that they are industry-standard and well-tested in different situations which has taken best practices while writing your own functions give that power to you to write minimum codes with better and more desirable responses as well as ability to debug which can not be ignored in such situations.
We've been having a discussion at work about whether to use Domain Objects in our views (asp.net mvc 2) or should every view that requires data be sent a ViewModel?
I was wondering if anyone had any pros/cons on this subject that they could shed some light on?
Thank you
I like to segregate my Domain Objects from my Views. As far as I'm concerned, my Domain Objects are solely for the purpose of representing the Domain of the application, now how the application is displayed.
The presentation layer should not contain any domain logic. Everything they display should be pre-determined by their Controller. The ideal way to ensure this is always adhered to is to ensure the view only receives these flattened ViewModels.
I did ask a similar question myself. Here's a quote from the answer I accepted:
I think that there are merits to
having a different design in the
domain than in the presentation layer.
So conceptually you are actually
looking at two different models, one
for the domain layer and one for the
presentation layer. Each of the models
is optimized for their purpose.
If I have the domain objects for Customer > Sales > Dispatch Address, then I don't want to have to deal with the object traversal in my view. I create a flattened view model that contains all of the properties. There's almost no extra work in mapping to and from this flattened view/presentation model if you use the excellent open source project AutoMapper.
Also, why would you want to pass an entire domain object back to a view if you can create an optimised representation of that model?
If you use NHibernate or similar - your domain objects will most likely be proxies, serializing these dun work. You should always use a ViewModel and map your domain objects to DTOs within your viewmodel. Don't take shortcuts here. Setting the convention will alleviate the pain you'll suffer later on.
It's a standard pattern for a reason.
w://
It depends. In some case it will be fine to use instances of model classes. In other cases a separate ViewModel is the better choice. In my experience it is perfectly acceptable to have different models in your domain and in your views. Or to use the domain model in the view. Do what works best for you. Do a spike for each option, see what works and then decide. You can even choose a different option for each view (and/or partial).
There are definitely going to be simple little apps where it's fine to use the same models across all layers. Generally little forms over data apps. But for a proper domain, my thoughts on the subject are to keep the domain models and view models separate because you don't want them to ever impact each other when changed.
If the domain logic needs a small change to process some new business logic on the back end, you don't want to risk that altering your view. Conversely, if marketing or someone wants to make changes to a view, you don't want those changes leaking back into your domain (having to populate fields and maintain data for no other purpose than some view somewhere is going to use it).
I have a good comparision currently because I'm working on two projects using different approaches. I'm far from stating that "this is bad and this is good" because this is written in some patterns. I know patterns, I like patterns, but I never blindly follow them just to be right. I always use what do I need currently to achieve current goals.
In first app, using domain objects in view, development is very quick. Few changes in few places and you have additional properties, form inputs etc. You don't bother about the layers, just extends/change the code and pass to another problem.
In the second app, where there are always object for use here, there and somewhere else, there's a dozens of classes looking the same, doing the same, and a ton of conversion code between various version of the same objects. More bad is that some developers do some logic on "this version" of class, and other logic is done on "that version". Development is very painful and requires a lot of testing afterwards. Changing a simple thing requires a lot of attention and a lot of code need to be changed. I really don't like this app for that, because I've never yet seen a business benefits from this approach, at least during last year (and we are in the production stage from the year). This app is three-four times more expensive to develop and maintain than the first one.
So, my funny answer on the question is: it depends. If you work in 10-20 people team, you like to come into the work, drink few coffies, talk with friend, do few simple things and go home, a lot of intermediate objects and conversion code will be good for you. If your goal is to be fast and cheap, if you want to focus on business layer, new features, quick changes following, and more if you touch software business and want to cash your project (we do all this stuff to be finally sold, right?), the second approach would be probably better.
Because the RoleProvider interface seems to treat roles as nothing more than simple strings, I'm wondering if there is any non-hacky way to apply an optional value for a role on a per-user basis.
Our current login management system implements roles as key-value pairs, where the value part is optional and usually used to clarify or limit the permissions granted by a role.
For example, a role 'editor' might contain a user 'barry', but for 'barry' it will have an optional value 'raptors', which the system would interpret to mean that Barry can only edit articles filed under the 'raptors' category.
I have seen elsewhere a suggestion to simply create additional delimited roles, such as 'editor.raptors' or somesuch. That's not really going to be ideal because it would bloat the number of roles greatly, and I can tell it's going to be a very hard sell to replace our current implementation (which is also very less than ideal, but has the advantage of being custom made to work with our user database).
I can tell already that the concatenation method mentioned above is going to involve a lot of tedious string-splitting and partial matching.
Is there a better way?
EDIT: My initial goal was to use more built-in ASP.NET functionality. For instance, control access via <authorization/> elements in the Web.config. Doing this, as far as I can see, requires implementing roles themselves. Our current system's concept of auths seemed to fit very well apart from that one limitation.
Answering mnemosyn's questions
Yes. We have a central database for users, applications and their authorisations. It's a core system and there's no going around it.
Currently our system is not hierarchical, and it actually takes quite a lot of effort to maintain. When an application is created, a set of authorisations are defined (e.g., 'admin', 'user', 'poweruser', 'gatekeeper', 'keymaster', etc.). Users are then associated with those authorisations with the optional value for a unique combination of user and (app-specific) authorisation.
Can you elaborate on these 'categories' of which you speak?
This really sounds like an architectural issue to me.
First, you need to determine what you need, exactly. In a second step, map this to a concrete implementation. To jump ahead on that one: I wouldn't use the built-in providers for anything but the most simplistic cases. Also, this problem quickly gets very complicated, so I'd try to keep it as simple as possible.
To elaborate your needs, try to determine:
Do you really need to map the role concept to the database, as you would in a CMS? Or do changes to your role system imply a modification to the system. In that case, you could go for a much simpler solution and put an enum into the user. This will save a lot of database accesses, makes joins simple selects, etc.
What are you trying to achieve through the multi-role concept you explained? Is it really roles that you need? How about individual permissions? Do you, for instance, have a hierarchical structure so that every node can have a certain set of permissions associated with it, much like windows' file security concept?
If it's only categories, why not map categories to users, i.e. give each user a certain role in each category. This will require some tweaks for default category, etc.
A few tips there: Don't go for whitelists, always use blacklists. Controlling whitelists is a pain, esp. when a lot of rules come together. In drupal, for example, I think this is one of the major flaws (which is why they're rebuilding it to use blacklists in version 7). Allowing a user to do something they shouldn't is usually a much bigger issue than the other way around.
The windows file access concept is very complicated, because it has both black- and whitelisting, which additionally can be inherited - so try to keep your solution much simpler than that.
The string concatenation thingie sounds rather dangerous to me, I'd go for a cleaner solution in any case. This type of meta-logic gives headache.
My question is possibly a subtle one:
Web services - are they extensions of the presentation/web layer? ..or are they extensions of the biz/data layer?
That may seem like a dumb question. Web services are an extension of the web tier. I'm not so sure though. I'm building a pretty standard webform with some AJAX-y features, and it seems to me I could build the web services in one of two ways:
they could retrieve data for me (biz/data layer extension).
example: GetUserData(userEmail)
where the web form has javascript on it that knows how to consume the user data and make changes to markup
they could return completely rendered user controls (html; extension of web layer)
example: RenderUserProfileControl(userEmail)
where the web form has simple/dumb js that only copies and pastes the web service html in to the form
I could see it working in either scenario, but I'm interested in different points of view... Thoughts?
In my mind, a web service has 2 characteristics:
it exposes data to external sources, i.e. other sources than the application they reside within. In this sense I agree with #Pete in that you're not really designing a web service; you're designing a helper class that responds to requests in a web-service-like fashion. A semantic distinction, perhaps, but one that's proved useful to me.
it returns data (and only data) in a format that is reusable by multiple consumers. For me this is the answer to your "why not #2" question - if you return web-control-like structures then you limit the usefulness of the web service to other potential callers. They must present the data the way you're returning it, and can't choose to represent it in another way, which minimises the usefulness (and re-usefulness) of the service as a whole.
All of that said, if what you really are looking at is a helper class that responds like a web-service and you only ever intend to use it in this one use case then you can do whatever you like, and your case #2 will work. From my perspective, though, it breaks the separation of responsibilities; you're combining data-access and rendering functions in the same class. I suspect that even if you don't care about MVC patterns option #2 will make your classes harder to maintain, and you're certainly limiting their future usefulness to you; if you ever wanted to access the same data but render it differently you'd need to refactor.
I would say definitely not #2, but #1 is valid.
I also think (and this is opinion) that web services as a data access layer is not ideal. The service has to have a little bit more value (in general - I am sure there are notable exceptions to this).
Even in scenario 1, this service is presenting the data that is available in the data layer, and is not part of the data layer itself, it's just that it's presenting data in a different format than a UI format (ie. JSON, xml etc.)
Regards which scenario I would use, I would go for scenario #1 as that service is reusable in other web forms and other scenarios.
While #1 (def. not #2) is generally the correct approach (expose just the data needed to the view layer and have all markup handled there), be careful with the web portion of the service in your design.
Data should only be exposed as a web service (SOAP/WSDL, REST) if it is meant to be consumed remotely (some SOA architects may argue this, but I think that is out of scope for this question), otherwise you are likely doing too much, and over-designing your request and response format. Use what makes sense for your application - an Ajax framework that facilitates client/server communication and abstracts the underlying format of communication can be a big help. The important thing is to nicely encapsulate the code that retrieves the data you want (you can call it a service, but likely it will just be a nicely written helper class) so it can be re-used, and then expose this data in whatever way makes the most sense for the given application.