I am currently teaching myself RDFa Core 1.1 after successfully learning RDFa Lite rather easily. Straight to the point, I can't understand two things: the difference between property and rel, and the difference between resource and about.
Please explain to me in simpler terms than the spec :)
property vs. rel:
Both attributes indicate a predicate of a triple, e.g. rel="http://purl.org/dc/terms/creator, which is the predicate ... has as a creator: ....
The difference is, from where they take their object. Slightly simplified, the rules for property are: The object is taken ...
from a valid content attribute or, if this is not present in the tag,
(if no datatype attr is present in the tag:) from a valid resource attribute or, if this is not present in the tag,
(if no datatype attr is present in the tag:) from a valid href attribute or, if this is not present in the tag,
(if no datatype attr is present in the tag:) from a valid src attribute or, if this is not present in the tag,
from the inner content of the element started by the tag.
Slightly simplified, rel differs in two aspects:
It takes its object only from a resource or a href or a src attribute.
It takes its object not only from an attribute of the same tag, but may also take it from descendant tags. The whole mechanism is called "chaining": "This is the main difference between #property and #rel: the latter induces chaining, whereas the former, usually, does not." 1 Usually, but property can induce chaining if used with typeof (cf. 2).
about vs resource:
about is the attribute to indicate the subject of a triple. The rules for resource are more complicated: It may indicate a subject or an object, and chaining plays a role here, too.
IMHO, chaining is the most complicated and confusing part of RDFa (and does not give you more than syntactic sugar). I would avoid chaining. This is possible by avoiding the attributes rel, rev, resource and typeof, which brings some further simplification at the same time. Thus, I use only the following attributes:
about for the subject
property for the predicate
content or href or src (or the inner content of the element) for the object, following the rules outlined above
lang for a language tag for object literals, e.g. lang="en"
datatype for a datatype tag for object literals
prefix (but only once in a document), so that I can abbreviate URLs by prefixing, e.g. property="dc:creator"
vocab (rarely and at the most once in a document), so that I can abbreviate URLs implicitly, e.g. property="creator".
(And I use the tag <base href="..."> to indicate the URL base value of the document.)
This is a strict, safe, easy-to-use and easy-to-parse subset of RDFa and allows to express any triple you want.
I would personally recommend to ignore / avoid using rel and about, they are not really necessary to write RDFa if you follow the rule of thumb that you should not try to be too smart by stuffing as many attributes as possible in a given HTML element. There are around for backward compatibility reasons. The other attributes from 1.1 are worth learning though: content and datatype.
Stephan's advice is in general conformance with RDF Lite 1.1, which does not include #rel or #about for precisely these reasons.
Another good rule of thumb is to not try to include markup of more than one entity on a given element, which was often an example of specifying an images license.
#property and #rel are very similar to each others, but served different purposes in RDFa 1.0, but this was confusing, even for experts. (Formerly, #rel was used for specifying objects which are other nodes, and #property was used for specifying literal values. While there are some remaining differences, but sticking to non-clever markup, you can do everything with #property that you could do with #rel.
Similarly, #about can be avoided to just use #resource. The difference is that #about sets the current subject and #resource the current object, but for child nodes the parent object (taken from the parent's current object becomes the current subject. There were another minor differences concerning the presence of #typeof, but if you only use #resource, it pretty much does what you want.
To summarize the best practices from RDFa Lite 1.1 you can also check out the RDFa 1.1 Primer:
stick to #vocab, #prefix, #property, #resource, and #typeof
avoid making more than one statement in a given element
Related
With ValueTuple in C# 7, it is now possible to write methods and properties that return or consume composite objects without explicitly declaring a type. These named tuples can however be potentially confusing when no documentation is provided.
As the primary and probably most convenient way of documenting libraries is by using XML documentation, is there any way using XML documentation to provide a description of the variables in a named tuple?
I know the obvious solution is to declare a type and document it accordingly. However, granted that due to some 'reasons' that cannot be done, is it possible to XML document the data members in a ValueTuple?
NB: A similar question was asked before the advent of the ValueTuple.
C# has no special syntax for documenting named elements of a tuple, you will have to use the normal <returns> and <param> elements and explain in words what each named element contains.
Though there is a proposal for adding this capability to the language.
In the example I made every object of the type "Folder" have an array of type "File" with the name "content" a size of "n" as a private attribute (just saying my understanding of it to make sure that I am not already wrong there). That's how I see it in most examples but I never understand what "n" now is. Is it another attribute of the "Folder" object or is it something that we specify in another part of an UML diagram or something else completely?
What I am trying to achieve is that every object of the type "Folder" has an additional attribute that specifies the size of the "content" array.
Of course, you can not only write 0..*, but use any concrete number, too. If that number has some external definition, you can use there n, as you have it.
The external definition means "not defined by class diagram elements, except notes". Everything that you need to be said on a class diagram page, but can't because of the UML limitations, should be put in a note.
So, n can be defined in appropriate note on the page or in some different document or both.
As #Kilian had mentioned, in the case of some more complicated dependencies of such variables you can use constraints. This way seems to me the most powerful.
But if n has no objective definition or dependency, but is a simple variable that can have any meaning, then it will be correct to use a rule, such as 0..*, or 1..*, or maybe 3..5, according to the reality you are working with.
is there a default visibility in UML2 if I don't (want to) add one of the four reserved visibilities?
As I know there is + for public, - for private, # for protected and ~ for package.
Or is the default depend on the implementation language that should be used, e.g. package for Java or private for C++?
Thanks so far.
If you don't add it then it's a don't care. Languages itself have their own rules and UML does not know how a language will treat it. The same goes for tools. They place one of the symbols (either public or private) as default and you eventually can change a default to something else. But again UML does not care.
Depending on how you use it you can tell the reader that a missing symbol will mean this or that.
Edit 1: Thanks to #xmojmr digging into the UML spec and the great critic uml-diagrams.org here are two statements. OMG first (SS2.4.1):
7.3.38 Package (from Kernel)...The query makesVisible() defines whether a Package makes an element visible outside itself. Elements
with no visibility and elements with public visibility are made
visible" and "7.3.39 PackageableElement (from Kernel)...
visibility...Default value is public
and from http://www.uml-diagrams.org/property.html
Note, that there is no default visibility. Also, visibility may be suppressed from being displayed on a diagram, even if it has some value in the model (e.g. stored by UML tool). So, if visibility is not shown on a diagram, it was either not specified or suppressed
Please also note that my original statement was just an expression of my experience from using UML in the real world. Feels good to see that my experience seems to be in synch with the theories ;-)
Edit 2: Looking into the 2.5 specs I found this in chap. 7.8 Classifier Descriptions on p. 48:
Attributes
- visibility : VisibilityKind [0..1] = public
A PackageableElement must have a visibility specified if it is owned by a Namespace. The default visibility is public.
Constraints
- namespace_needs_visibility
A PackageableElement owned by a Namespace must have a visibility.
inv: visibility = null implies namespace = null
So it says the default is public. But the constraint says it must have a visibility. Which to me means that you need to specify it?
If you don't understand definition, read the definition for definition :-/
My XML files have restrictions on the child elements, but it really doesn't matter what the name of the root element is. How can I incorporate this into my XSD? I've tried using <xs:any> but I get:
"S4s-elt-invalid-content.1: The Content Of 'schema' Is Invalid. Element 'any' Is Invalid, Misplaced, Or Occurs Too Often."
So I tried missing the name off the element tag like this: <xs:element> but then I get:
"S4s-att-must-appear: Attribute 'name' Must Appear In Element 'element'."
Use a named type, and tell your validator to start validation at the root element using that type.
(There is one possible hitch with this: XSD 1.0 suggests that as one possible invocation option, but does not require validators to provide it, so there's no guarantee the validator interface you use will support it. Depends on your validator. Worth trying, at least.)
Another way to put this: you already have what you are asking for, because your XSD schema never cares what the root element of your document instance is called. An XSD schema provides a set of element and type declarations (among other things). A validator can be requested to start the validation at any point in the document, not just the root, and with either an element declaration or a type declaration, or in 'lax wildcard mode' (the most common default). If your validator doesn't offer the invocation options you want, it's a flaw in your choice of validator, not a gap in XSD.
I think I might just make the requirement stricter and insist on using a particular tag as the root element. The fact that the application doesn't care is not really a problem.
It seems (to me) strange that this limitation exists, but I am new to XSDs.
In the context of Domain Driven Design, is a StackOverflow tag (ie. ddd ) a value object or entity?
EDIT:
Imagine, that you have to build SO website. How would you consider 'tag'?
To expand a little on awhite's answer
a tag is a value type
Why?
Because it doesn't make sense to have
var tag1 = new Tag("DDD");
var tag2 = new Tag("DDD");
Assert.AreNotEqual(tag1, tag2);
clearly they should be equal to each other because a tag has no identity except for its label. Questions and answers on the other hand are definitely entities
SO tag is most likely an entity. Tags can be created, merged, deleted and renamed. There are features like 'similar tags', user's tags etc. Some of these functions, especially life cycle, will require an identity. Classic DDD example where Person that changes his/her name is still the same person, the same identity. The same with tags where user can decide to rename "domain-driven-design" to "DDD" and it will still be the same thing. Tags also need additional attributes like tag.Id, tag.Name, tag.CreatedOn, tag.CreatedBy, tag.Locked etc. There would probably be a corresponding tags repository that can enforce name uniqueness rule.
To summarize, SO Tag is not a DDD Value Object because it is mutable and has a life cycle. More importantly, Tag is not only a characteristic of a Question (this is what I think was overlooked by other answers). It participates in a lot more relationships than that. In other words, Tag is more than just a sum of its attributes, it also has 'conceptual identity'. On the other hand TagName is a perfect example of Value Object. Its only purpose in life is to describe another entity (Tag). TagName is nothing more than just a string that may have a few built in rules like max length and case insensitive comparison. It may also make sense to simply use String instead.
Code that displays questions may use something like this:
IList<TagName> tags = question.GetTags();
Code that tags the question can look like this:
void TagQuestion(Question q, TagName tagName) {
Tag tag = _tagsRepository.FindByName(tagName);
if (tag == null) {
tag = CreateNewTag( /* capture creator, date, other rules*/);
}
q.AddTag(tag);
}
Just some additional considerations: Tags can be normalized, "DDD" should be equal to "ddd" and "DdD", and in most tag systems, spaces get replaced with "_" underscores. Also I guess the creator will be tracked for the badge system.