I am new to Semantic Web, and don't quite know what is the terminology for having instances of the same concepts or same inherited concepts? Can we call the instances equal if they belong to the same concept or subconcept?
Two instances of the same concept are in the same class. You can't really say anything more than than that. Suppose you have a concept Colour, and two instances red and green. They (presumably) aren't equal, but they are both members the Colour class, and may jointly be members of other classes as well (e.g. PrimaryColours, TrafficLightColours).
Note that I say that red and green may not be equal. In the semantic web, we generally make the open world assumption, i.e. that we don't assume that we have all of the relevant information yet, and we don't make the unique name assumption - so things with different names may denote the same thing. So unless red and green are explicitly stated to be different (owl:differentFrom), it's possible that, under the open world assumption, new information could show up to say, or infer, that they actually denote the same resource (owl:sameAs)
The equals method on a Jena Resource works out whether one resource is the same as another, not the same type as another. To work this out something like this will suffice:
if (resource1.hasProperty(model.createProperty("http://www.w3.org/1999/02/22-rdf-syntax-ns#", "type"), model.createResource("http://typeUri")) && resource2.hasProperty(model.createProperty("http://www.w3.org/1999/02/22-rdf-syntax-ns#", "type"), model.createResource("http://typeUri"))) {
// both resources are the same type
}
Related
The CSS allows that I can have a class called “.header”, as well as “.main”, “.footer”, “.aside” and so on... the same for IDs. In theory, I can have 3 selectors with almost the “same” name, like “article”, “.article” and “#article”. And I can do the same with all elements, including, why not, a class called “.html” and an ID called “#body”, etc.
For me, if I see the DOT I know that is a class, and if I see the HASH, I know that is an ID, so for me no confusions, but does it go against the naming conventions?
Yup, you absolutely can. If you’re the only one working on the project, and if this is intuitive to you, go right ahead, no issues.
But when working with a larger team, it generally makes sense to use ids and classes that are little more descriptive in nature. For example, .left-primary-sidebar would tell me a whole lot more about the element than something like .aside, when going through the stylesheet.
Your naming choices are definitely valid.
Naming conventions can differ from company to company, so if you’re the only one working on the repo, you can set your own conventions.
according to the DOM Core,
Attr objects inherit the Node interface, but since they are not actually child nodes of the element they describe, the DOM does not consider them part of the document tree.
and also
The DOM takes the view that attributes are properties of elements rather than having a separate identity from the elements they are associated with
Given this, what is the advantage of Attr objects inheriting from Node?
The DOM Spec states:
Attr nodes participate in a tree for historical reasons; they never have a (non-null) parent or any children and are therefore alone in a tree.
which is a partial answer, but I'm wondering if anyone has any deeper explination of Attr's Node inheritance and tree participation than simply "historical reasons".
Sorry if this is a duplicate question, most questions I've found revolve around the behavior of Attr objects, rather than the rationale behind their structure.
With a "why" question, you need to be very clear whether you are asking
what are the potential benefits of this decision?, or
historically, what arguments were put forward and why did individual committee members vote the way they did (if indeed there was a discussion and a vote)?
In most cases the second question is unanswerable, though in a few cases (such as the Annotated XML specification by Tim Bray) you can at least see the rationale put forward by one of the editors.
To me the decision feels like a compromise. Attributes have many properties in common with other nodes, so there's an advantage in having them implement the same interface; but there's baggage that you don't really want because it might add unnecessary cost, like having a link to the containing element.
Frankly, DOM is not a good piece of design, and it's very hard to say why it made so many design mistakes, other than that it was put together by a committee in a hurry. Later models such as JDOM and XOM are much better, but sadly not available for Javascript.
I have been brushing up on my XML schema skills the past few days and during a whole day I was busy trying to understand the intricacies of namespaces with respect to schemas. What struck me most was the seemingly uselessness of the form="qualified|unqualified" attribute on non-global <element> and <attribute> elements.
My question is: does the form attribute actually add expressivity to XML schemas / XML documents, or does it just make the notation of certain XML documents easier/different?
I understand that XML documents that need to conform to a certain schema are generally easier to write when all elements are to be qualified with a namespace (one xmlns="xyz" attribute on the document element is all you need), but is that all? Why would anyone bother with unqualified non-global elements at all?
First, on the formal question: does the form attribute actually add to the expressivity of XSD? I think so: with the form attribute I can write types whose sets of valid instances cannot (as far as I can see) be matched by any type written without using the form attribute.
For example (in a schema which defines a top-level element named a of type duration):
<choice maxOccurs="unbounded">
<element form="qualified" name="a" type="integer"/>
<element form="unqualified" name="a" type="gYear"/>
</choice>
Then, on the less formal question: why would anyone bother?
The short answer is: because for each possible way of choosing among qualified and unqualified names for local elements and attributes, some people think that that is the right way to declare local elements and/or attributes.
A longer answer will take a little time. Sit down, get yourself a cup of coffee.
There are two schools of thought on local elements; both were represented in the working group that designed XSD.
One school of thought believes that if element P is in namespace N, and element C is local to the type of element N:P, then it is only natural that the child element should be named N:C. It is, after all, part of the same vocabulary as P, and identifying the vocabulary is what namespaces are all about. From your final question, I guess you lean toward this way of seeing things.
The other school of thought reasons that local elements are like local attributes. An attribute local to (the type of) element N:P is named A, not N:A -- the name N:A denotes, by definition, an attribute global to namespace N, not local to element N:P. By analogy, local children should also use unqualified names, so that attributes and child elements are treated in similar ways.
The presence of the form attribute on XSD element and attribute declarations might suggest the possible existence of a third school of thought, characterized by a desire to treat the choice between qualified and unqualified names as a design choice to be taken individually for each local element or attribute, and not necessarily in a single vocabulary-wide edict. For what it's worth, this third school of thought doesn't actually seem to exist. At least, I don't think I've ever encountered a member. No one ever seems to set out to write complex types of the kind exhibited above with mixtures of qualified and unqualified local names. The essential function of the form attribute is not to allow different local elements to be qualified or unqualified, but to have its default set by the elementFormDefault and attributeFormDefault attributes on the enclosing schema element, thus ensuring that even if schema authors are somehow stuck with the wrong values for those attributes, they can still get the effect they desire.
I have also never (that I know of) encountered any member of either of the first two schools of thought who could feel any sympathy at all for the reasoning of the other school. That anyone could think the way the members of the other school of thought think has pretty much always come as an unwelcome surprise. With a little effort, smart people of good will find it possible to accept the existence of the other school of thought, and even (with a little more effort) to accept that the members of that school of thought are arguing in good faith, and are not just trying to gum up the works. The variety of views has anthropological interest at best (look at the very odd things people can claim to believe even when otherwise they seem mostly like more or less rational beings! Funny old world, isn't it?). After some months of deadlock most members of the working group were forced to admit to themselves that they just were not going to be able to persuade the other guys to see the error of their ways.
It then became clear that pretty much everyone in the WG had the same ranking for the three possibilities we could think of:
Define things the way I think is right.
Define things so that the schema author must make the choice.
Define things the way the other guys think is right.
Everyone liked the first choice (for suitable values of "I"), but for different WG members "the way I think is right" turned out to denote different things.
No one much liked the second choice, since it makes the schema author's life harder and leads to less consistency in the universe of schemas.
But everyone hated the third choice (being forced to do things the way the other guys wanted) so much that they were willing to accept compromise rather than risk utter defeat.
I have a query In our application we have lots of HTML tags. During development many tags were not given any id because of no requirement.Now the QA team wants to automate the test cases using QTP. In most of the cases this tool doesn't recognizes because it does not find ids for most of the HTML tags.Now we are asked to add ids to all the HTML tags.
I want to know if there will be any effect adding id attribute to these tags. Even positive impact are welcome
I do not think there will be any either positive or negative effect : maybe the size of the HTML page will increase a bit, but probably not that much.
Still, are you sure you need to put "id" attributes on every HTML tag of your pages ? Wouldn't only a few of those be enough ? Like on form fields, on links, on error-messages ; and that's probably about it ?
One thing you must take care, though, is that "id", as in "identifers", must be unique ; which implies it might be good, before starting adding them, to define some kind of "id-policy", to say, for instance, that "ids for elements of that kind should be named that way".
And, for your next projects : have developpers add those when theyr're developping ;-)
(And following the policy, of course)
Now that I'm thinking about it : a positive effect might be that it'll be easier to write Javascript code interacting with your HTML document -- but that'll be true for next projects or evolutions for this one, when those id are already present in the HTML at the time developpers put the JS code in place...
Since there are no QTP related answers yet.
GUI recognition in QTP is object-oriented. In order to identify an object QTP needs a unique combination of object's properties, and checking them better to be as fast as possible - that is why HTML ID would be ideal.
Now, where it is especially critical - for objects that do not have other unique identifiers. The most typical example - html tables. Their contents is dynamic, their number on the page may vary. By adding HTML ID you allow recognition mechanism get straight to the right table.
Objects with other unique properties can be recognized well without HTML ID. For example, if you have a single "submit" link on the page QTP will successfully recognize it by inner text.
So the context-specific answer: don't start adding ids to every single tag. Ask automation guys to prepare a list of objects they have problem with. And add ids to those objects.
PS. It also depends on automation programming skills. There are descriptive programming and dynamic recognition methods. They allow retrieving the right objects even without ids provided.
As Albert said, QTP doesn't rely solely on elements' id, in fact due to the fact that many web applications generate different ids for each session, (as far as I remember) the id property isn't part of the default description for most web test objects.
QTP is pretty good at recognizing most simple web controls and if you're facing problems it may be the case that a Web Extensibility project will help you bridge the gap between the semantics of your web application and the raw HTML it is created in. If a complex control is recognized by QTP as a WebElement (which is actually the div that contains the span that drives the code) you will understandably have object recognition problems since there are many divs on the page but probably many less complex controls.
If you are talking about side-effects - NO. Adding ids won't cause any problems (apart from taking up some extra bytes of course)
If you really have the need to add ids, go ahead and add them.
http://www.w3.org/TR/html4/struct/links.html#anchors-with-id says: The id and name attributes share the same name space. This means that they cannot both define an anchor with the same name in the same document. It is permissible to use both attributes to specify an element's unique identifier for the following elements: A, APPLET, FORM, FRAME, IFRAME, IMG, and MAP. When both attributes are used on a single element, their values must be identical.
I sometimes end up with a class hierarchy where I have an abstract base class with some common functionality and a couple of implementing classes that fall into two (rarely more) groups which I want to treat differently in some cases. An example would be an abstract tree node class and different branch and leaf implementations where I want to distinguish branches and leaves at some point.
These intermediate classes are then only used for "is-a" statements in flow control and they don't contain any code, although I have had cases where they "grew" some code later.
Does that seem smelly to you? In my tree example, one alternative would be to add isLeaf() / isBranch() abstract methods to the base class and implement those on the intermediate classes, but that didn't seem to be any better to me, really, unless I'd mean to have classes that could be multiple things at once.
To me, using "is-a" tests in flow control is just as smelly as using switch/case. In a good OO design, neither is needed.
Yes, deep inheritance hierarchies are a code smell anyway.
Yup, definitely a code smell -- don't code these empty classes unless you're ready to write that code into it. Think YAGNI (you aint gonna need it) -- don't do it unless you need it already.
Also, have you considered cases wherein these classes are only there to provide abstract methods, or to group them based on capabilities in terms of methods or properties?
If that's the case, maybe what you really need are interfaces, not additional abstract classes?
In general, empty classes are a code smell.
I agree your isLeaf or isBranch methods are a correct alternative.
They add information about the objects , which is helpful.
(This is because, on the super class, you can't express that subclasses are "either leaf or branch").
The two methods with opposite results might also be considered as code duplication.
You could use only one... But I would recommend return an enumerated value LEAF or BRANCH.
A class that doesn't contain any code is definitely a code-smell....
Seems alright to me, if you're going to put new functionality in later.
But if not, an enum is generally used here.
-- Edit
Though I must agree with Ber, that you shouldn't generally be using 'is-a' anyway.