(one of the InLOC Bindings)
- 1 Introduction
- 1.1 Conventions for RDF graph diagrams in this document
- 1.2 Representing the information model in RDF
- 1.3 Naturalized RDF
- 2 LOC structures and definitions
- 2.1 Turtle preamble with prefixes
- 2.2 A LOC structure with its direct properties
- 2.3 LOC definitions
- 2.4 Graph for LOC structure and definitions
- 3 LOC associations
- 3.1 A "by" association
- 3.2 A "LOCrel" association with no number
- 3.3 A "LOCrel" association with a number
- 3.4 Some "category" associations
- 3.5 A "credit" association
- 3.6 A "level" association
- 3.7 A "topic" association
- 3.8 Graph for LOC associations
- 4 Other considerations
- 4.1 Sub-structures
- 4.2 Other information that could be added in RDF
- 4.3 Variant predicate IRIs
- 4.4 Unexpected literal values
- 5 Use of the naturalized RDF binding
- 5.1 RDFS ontology for naturalized RDF binding
- 5.2 How to convert InLOC naturalized RDF triples to XML
- 6 Further reading
For an introduction to RDF, there are several well-known sources, including:
As explained in the Wikipedia article, "RDF is an abstract model with several serialization formats". But because they all conform to the same underlying model, they are all in principle inter-convertible. Of particular interest for this documentation are:
- Turtle, particularly for the prefix conventions, to make the examples as easy to read as possible;
- N-Triples, one of the simplest formats, which could be used for the most straightforward processing. See this section on N-Triples from RDF test cases.
Over recent years, the term "URI" standing for "uniform resource identifier" has gradually migrated to "IRI", standing for "internationalized resource identifier", in contexts where the ability to use extensive character sets would be useful, as it is here. Therefore, the term "IRI" is used in preference in this binding. "IRI references", that is, IRIs, enclosed between < and > characters, are used in Turtle and N-Triples to identify "resources". This is not the place to discuss what a resource might be in general, but for InLOC purposes, it is definitions or descriptions of concepts of ability, competence, knowledge, level, skill, etc., and documents and structures containing these, that are the "resources" of primary interest.
The example given here initially corresponds to the Vitae Researcher Development Framework worked example. To distinguish the two "RDF"s, Vitae's one will here be abbreviated either VitaeRDF or VRDF. Plain "RDF" will mean the Resource Description Framework. The example is taken from published materials, but is not yet endorsed by Vitae, the owner of the Researcher Development Framework. In particular, the allocation of the VRDF prefix is entirely provisional and unofficial.
This InLOC documentation now gives graphical representations, as are commonly used when explaining RDF, Linked Data, and the Semantic Web (as for example in the RDF Primer).
The main binding requirement from the stakeholders known to the project was XML, rather than RDF. To naturalize an information model for XML is rather different than to naturalize it for RDF, and the InLOC information model is naturalized primarily for XML.
The InLOC information model uses the LOCassociation structure in a way not unlike an RDF triple, but it is not structured in exactly the same way as a triple in RDF/XML. To use the full power of RDF and associated technologies such as SPARQL and OWL, specific kinds of LOC association should be represented as actual triples. This results in a more compact representation, more natural for RDF in a Semantic Web context.
The original InLOC information model is shown elsewhere in the form of a UML diagram, and in a different way in the InLOC information model diagram. As RDF is composed of triples, the model diagrams here are adapted to show either the form of triples, or the actual triples. Each triple is composed of a subject, a predicate and an object.
- The subject of the triple is a resource shown as an oval at the start of a directed arc.
- Predicates are represented by the labels in the middle of arcs, shown here as green rectangles.
- The object is the resource or literal at the end of an arc:
- an oval object represents a resource;
- a rectangular object represents a literal.
- Most of the colours are borrowed from the same information model diagram in the Guidelines.
The InLOC information model was initially developed with an XML binding in mind. Translating this to RDF would result in something like Figure 1. Here, arrow heads are put only on the second part of the arc, joining the predicate to the object. The arrow head is by the object.
However, note that this representation is NOT USED for the InLOC RDF binding.
Figure 1: the original InLOC information model interpreted for RDF, but NOT USED
This compares easily to that information model diagram in the Guidelines section on InLOC explained through example. One important difference is that, in RDF, the identifier of the resources is the IRI that stands for the subject, predicate or object. This means that normally, as long as the identifier is an IRI, it does not need to appear separately in the RDF model.
For RDF to follow the original information model, it needs predicates that have been defined in the information model, but were not used in the XML binding (as they were not necessary). Very similarly to the XML binding, both LOC structures and LOC definitions are the subject of several straightforward triples expressing many of their direct properties. However, there is no explicit "id" triple for LOC structures or definitions, because the IRI that was the id attribute in the XML binding stands as the subject or object of the triple itself. The language is represented by the same code, but a default language for a LOC structure needs to be given its own triple with the language predicate. Literals that can appear in several language versions have different languages distinguished by a language tag appended to the string, in place of XML's xml:lang attribute.
To avoid the need to nest XML, LOC structures contain LOC associations, which express the relationships and compound properties of both LOC structures and definitions. Thus, for a corresponding RDF representation, LOC structures would become the subject of triples with the predicate "comprisesAssociation" (not used in the XML binding), where the object is each contained LOCassociation. LOCassociations in turn would have three predicates "hasSubject", "hasScheme" and "hasObject", not used as XML element names, having the subject, scheme and object as their respective objects. LOCassociation, subject, scheme and object are never required to be referred to from outside the particular LOCstructure that is being represented.
Though this structure is neat, it is not as one would expect of an RDF model for Linked Data or the Semantic Web. The relationships between LOC structures and definitions are represented only through being the literal identifiers that are the object of triples with "id" predicates. It is not easy to use these in queries, as the linked data is linked only indirectly. Therefore, this approach is NOT USED for the InLOC RDF binding, but instead an alternative approach is followed, as follows.
For a more natural RDF approach, just a few aspects of the model need to be slightly rearranged. The direct properties from language to combinationRules are still represented in exactly the same way as for the version following the original information model in Figure 1. But the role of the LOC association changes. There is no nesting in any case in Turtle or N-Triples, and so no need to avoid it. Instead, the LOC structure or definition, as appropriate, can become the subject of any triples referring to it, so the subject is no longer given within a LOCassociation.
Following this approach, the main change from Figure 1 to 2 is that instead of the uniform LOCassociation construct, relationships and compound properties are treated differently. For relationships of LOC structures and definitions, triples can be used in a completely natural way. For compound properties of type by, the scheme id also becomes the predicate of the triple, so there is no need for a separate scheme; the object becomes the RDF object of the triple. For the other kinds of compound property, triples are constructed with the subject as either a LOC structure or definition, and an "association resource" as object, which could be a RDF blank node. Further triples link this association resource to the scheme and the object, just as they appear in the original information model.
Figure 2 below shows how the RDF is changed to naturalize it for Linked Data and the Semantic Web.
Figure 2: The InLOC information model, as modified for naturalized RDF
In the original information model, the type property of LOCassociation was listed as one of the six values allowed by InLOC. For naturalized RDF, it is the predicate itself that represents the type, either explicitly, or by the predicate being a sub-property of the types LOCrel or by.
Structural LOCrel predicates (e.g. hasLOCpart) only have LOCstructure or LOCdefinition as objects, so these are the simplest cases, and distinguished in Figure 2 by being placed between the LOCstructure and LOCdefinition graphics. Associative LOCrel and by predicates need no further information to specify what is the scheme in the original information model. They are therefore placed in the central column of predicates.
The other kind of associations – category, credit, level and topic, still need their scheme specifying, and may have several kinds of InLOC object. So, they are introduced as an "association triple" with a LOCstructure or LOCdefinition as subject, their own IRI as predicate, and an "association resource" as the triple object. That resource is then the subject of "secondary" triples: a "hasScheme" triple links to whatever represents the scheme, and a "hasObject" triple links to whatever represents the object, similarly to the original information model, and not very different from Figure 1. But, instead of the fixed containers for scheme and object in the information model, RDF offers the opportunity to distinguish:
- another RDF resource, that is, identified by an IRI;
- or a "supplementary" blank node, where there is no IRI defined.
The number predicate has its own triples, with a decimal literal object and two possible kinds of subject:
This in turn means that each LOCdefinition can be associated with at most one number, which is another restriction to the generality of this naturalized representation. If one LOCdefinition is represented meaningfully with two different numbers, then for naturalized RDF the LOCdefinition would need to be split into two, with different ids.
In this naturalized RDF approach, one cannot simply create different labels (in the same language) for the same scheme or object, as one can within the XML LOCassociation structure, because there is no easy way of distinguishing different labels (in the same language) for the same scheme or object in different contexts. If there are schemes or objects that have had the same id in an XML binding, but need different labels (in the same language), it will be necessary to give them different ids, or represent them as blank nodes.
To summarise, these are the extra constraints that an InLOC representation must conform to, in order that the information is able to be fully represented in InLOC naturalized RDF.
- Every LOCstructure and LOCdefinition must have an IRI as an id.
- Every InLOC subject must be given as a LOCstructure or LOCdefinition.
- A LOCdefinition object of hasDefinedLevel cannot have more than one number.
- Any given scheme or object cannot have more than one label in any given language.
For the basic information about LOC structures and LOC definitions, both RDF representations introduced above would be the same. Figure 3 here shows the part of the RDF model that is covered in this section.
Figure 3: InLOC direct properties represented as RDF
Figure 3 shows the InLOC direct properties as they are represented in RDF – some of them may be classed as "resources" as an alternative to other literals, as already shown in Figure 1, because they can potentially be represented by an IRI.
In addition to the information already shown in Figures 1 and 2, Figure 3 shows triples with predicate "rdf:type", which also natural to any RDF representation – "rdf:type" is abbreviated in Turtle to "a". The IRIs of actual LOC structures or definitions do not indicate which they are – in XML this is done through the tag name. So there must be a triple stating whether each resource in the structure is a LOC structure or a LOC definition. The object of this triple is an IRI – either <http://purl.org/net/inloc/LOCstructure> (same as "inloc:LOCstructure") or <http://purl.org/net/inloc/LOCdefinition> (same as "inloc:LOCdefinition") accordingly.
With the XML binding, the relevant parts here would be as follows, with the Framework as a whole represented by the containing LOC structure, and with sample LOC definitions, which may be placed inside or outside the LOC structure.
This initial piece of RDF in Turtle syntax allows the easier reading of the triples following, by defining prefixes. All the following RDF snippets follow the same Turtle syntax, and assuming that all these prefixes have been defined.
If the N-Triples syntax is used, there are no prefixes, and all triples occur in their full form, with a full IRI for every subject and predicate.
LOC structures and LOC definitions, along with their direct properties, are represented simply with triples, and there is no difference between the different styles of RDF.
Here is the main structure in this example:
Note that the resource "VRDF:vitaerdf" is stated to be a LOC structure.
LOC definitions are represented a similar way. Naturally, instead of being an "inloc:LOCstructure" it is an "inloc:LOCdefinition". Most of the direct properties are here, as expected in most cases, inherited from the LOC structure, so the only direct properties needed are the title and/or description.
Here is one of the "Domains":
Every domain contains sub-domains. One of these is
Each sub-domain contains descriptors, e.g.
Finally, each descriptor has several phases of development, somewhat like levels in other frameworks. One of these is:
All the above triples are represented here graphically in Figure 4.
Figure 4: the same triples from the VRDF represented graphically
Figure 4 excludes triples representing LOC associations.
The six different types of LOC association have slightly different semantics, and therefore need illustrating separately. First illustrated here is the "by" type, which could be seen as the easiest; then the "LOCrel" type, followed by the rest of the LOC association types: "category"; "credit"; "level" and "topic".
All the associations are represented quite differently in the two RDF styles.
- The style following the original model mirrors the XML LOC association structure. This involves several RDF nodes, which are given in this illustration as blank nodes. The initial triple has the predicate comprisesAssociation.
- In contrast, the style naturalizing RDF does not represent the association directly, but conceives of the association as being represented by an initial "association triple", with the association's subject, scheme (as RDF predicate), and object. In most cases the object is represented by its IRI id, or a literal. The exception is for LOC associations of type credit, where a blank node must be used for the object, though differently from from when represented RDF following the original model.
The "by" associations are those that give the author, publisher, etc., usually of a LOC structure. It is also possible to give these properties of a LOC definition, when represented separately from its "home" LOC structure.
The example here gives the publisher of the whole framework. The relevant XML would be as follows. This snippet would be contained directly within the XML <LOCstructure> element.
If a graph were to be drawn following the original information model, it would look like Figure 5.
Figure 5: RDF graph for a "by" association from VRDF, following the original model – NOT USED.
This is hard to follow, which justifies this representation not being used for the InLOC RDF binding.
As the naturalized RDF discards the LOCassociation node, any IRI that might have been given for the LOC association (in an XML binding) will be discarded, as there is no place for it in the naturalized RDF representation. Instead of representing the type of LOCassociation as an IRI object of an id predicate, it is represented by the IRI being used as the actual predicate of the main triple.
The basic form is this.
There are some optional extras that can be added with extra triples:
- RDF provides an easy way to add on a language tag to any literal text value.
Multiple labels could be added, each with their own language.
- From an ontological point of view, publisher is a sub-property of by. If desired, this can be represented explicitly as
Figure 6 shows the the graph for this naturalized representation.
Figure 6: naturalized RDF graph for a "by" association within VRDF
Other similar relations can be represented in the same way, simply by replacing "publisher" with "creator", "contributor" or "rightsHolder" as appropriate, and changing the id and label of the agent.
A "LOCrel" association with no number
The "LOCrel" type of LOC association serves to relate together LOC structures and LOC definitions, making the structure of the LOC structure explicit. The example given here is the framework as a whole relating to one of its main parts, that is, one of the "domains".
Figure 7 shows an RDF graph for two of these relationships from the VRDF as it would look were the original information model to be followed closely. It is relatively very difficult to follow. This is further justification for the InLOC RDF binding not following the original information model closely, but changing it to a naturalized version.
Figure 7: RDF graph following the original model, showing the necessary complexity of this style of representation – NOT USED.
This is done similarly to "by" LOC associations. Instead of representing the type of LOCassociation as an IRI object of an id predicate, it is represented by the IRI being used as the actual predicate of the main triple. There is no need for any blank nodes. The single triple is clear and self-explanatory, being a triple that directly relates the relevant LOC structure and LOC definition. InLOC calls this an "association triple".
Whether to include this or not would depend on whether the receiving system knows the ontology.
The RDF graph for the naturalized style, Figure 8, is relatively very straightforward indeed.
Figure 8: naturalized RDF graph for two structural relations in the VRDF
In view of the much greater simplicity of the naturalized RDF graph, only this is illustrated in subsequent examples.
A "LOCrel" association with a number
The relationship hasDefinedLevel requires the use of a number, representing a numeric value for the defined level, in the sense that a greater number means greater competence, etc. The example here relates one of the VRDF "descriptors" to one of its "phases".
In this case, for the naturalized RDF representation, the number moves from being a property of the LOC association to being a property of the object. This depends on there being at most one number associated with each distinct object. In this case, the object can only be a LOCdefinition.
This may not be quite so immediately clear to a reader, but it is certainly has the minimum number of triples needed to convey the information. The restriction about each object having at most one number comes from the fact that triples are essentially separate, and that if a further triple was given with VRDF:B2-2_Ph2 having a number other that "2" this would cause ambiguity that could not be resolved.
Figure 9 gives the graph for the naturalized RDF.
Figure 9: naturalized RDF graph for a level definition in the VRDF
Vitae does not provide any external categorisation for any elements of their RDF. However, for some purposes it might be useful to know explicitly where any given LOC definition fits into the Vitae RDF scheme of things. So far, from the RDF given, it is only possible to work out whether a LOC definition is a "domain", a "sub-domain", a "descriptor" or a "phase" from the context of how many links it is from the framework as a whole. The framework as a whole is directly linked, through "hasLOCpart", to each "domain", the domains are directly linked to the subdomains, and so on. But there could be a category scheme that allows people to define directly what kind of LOC definition it is, in Vitae terms.
Reusing the example material from above, this example gives the Vitae category of the domain B, which is, of course, a "Domain" in Vitae's terms. A category file has been created to illustrate how the IRIs associated with category schemes and terms can work most simply in terms of the W3C concept of "Cool URIs for the Semantic Web" and static page on the web.
The first version of this assumes that both the category scheme and object are given as full IRIs.
If there is a non-IRI id, an extra blank node must be defined, and the (non-IRI) id given alongside the labels. This example is for a "Descriptor".
Figure 10 gives two different variants for representing category relation examples from the VRDF, depending on different assumptions about the identifiers that are desired. This mirrors the examples above.
Figure 10: naturalized RDF graph for category relations in the VRDF
The Vitae RDF is not the kind of framework that naturally has credits attached.
However, one can perhaps imagine that someone could base a funded course on the VDRF, with perhaps some of the VRDF phase definitions as intended learning outcomes of the course. Imagine that the Phase 2 descriptor was the learning outcome, and that it was associated with 10 ECTS credits. Being part of doctoral or postdoctoral work, it would seem natural to assign the highest ECTS level, called the "third cycle", to this. A footnote in the ECTS users guide states:
There is no consensus on the usefulness of credits for the third cycle, but technically it is possible to attach credits to any cycle.
The CEN Workshop Agreement from January 2010 – CWA 16077, "Educational Credit Information Model" – provides a model for educational credit information. This is an adaptation of a fragment of one of the examples given in CWA 16077, to fit the current example:
Represented as InLOC XML, this could be given as
Credit assignment must have a credit scheme, so the hasScheme triple is mandatory. But it is possible for a credit scheme to have no levels, in which case the hasObject triple and any related labels would simply be left out, with no adverse consequences.
Figure 11: naturalized RDF graph for an imagined credit association as if in the VRDF
The "level" association is used to map LOC structures or definitions to external levels.
The overall "stages" of the VRDF do look as if they might be mapped to other level schemes. Though the Vitae RDF doesn't actually do this, one could speculate that Phase 2 of "Commitment to research" might be associated with EQF level 5. It is not clear whether all the descriptors for the same phase belong to the same EQF level. If they did, there would be a case for making more of the Phases as substantive entities; making them into LOC definitions in their own right, as is done in the e-CF example, given with the XML binding.
The EQF gives separate descriptors of levels for knowledge, skill and competence. In this example, the labelling assumes that "eqf#5" just refers to the competence level, rather than the other two. If any knowledge or skill levels appear in the same framework, the ID should be changed accordingly, for instance in this case to "eqfc#5" as opposed to "eqfk#5" or "eqfs#5". In the naturalized RDF, there must only be one label for each separate explicit IRI.
To illustrate one aspect of best practice, here, the object is given an IRI as well.
Figure 12, in contrast to Figure 11, shows the use of RDF IRIs, instead of using extra blank nodes.
Figure 12: naturalized RDF graph for an imagined level association as if in the VRDF
The VITAE RDF doesn't have any explicit topics. (The term "subject" is sometimes used as a synonym for "topic", but here it would risk confusion with the subject of a triple.) One could, however, cross-reference some parts of the structure to, e.g., bibliographic classifications. Thus, perhaps, Vitae RDF B3, "Professional and career development", could be catalogued under UDC 377, "Specialized instruction. Vocational, technical, professional training. Vocational colleges, institutes. Polytechnics." It is not clear what the best IRI for the UDC system itself is. The Wikipedia article http://en.wikipedia.org/wiki/Universal_Decimal_Classification is unambiguously about it, but probably better is the IRI proposed by DCMI: http://purl.org/dc/terms/UDC, which is a "vocabulary encoding scheme". Though the method given here is not how DCMI envisage the use of their vocabulary encoding scheme, it does seem a reasonable approach, not subject to any ambiguity.
The decimal classification number itself is an identifier relative to the classification scheme, not universally unique, and not an IRI as such.
This is not wholly satisfactory, as it fails to include the version number or date of the bibliographic classification scheme. Ideally, an IRI for UDC would include at least one of these, to prevent ambiguity.
The IRI for the UDC system is used as the scheme.
In this case, as there is a non-IRI id for the object, a blank node is needed for the object.
Figure 13 shows how a topic association might be represented in naturalized RDF.
Figure 13: naturalized RDF graph for an imagined topic association as if in the VRDF
A selection of the above naturalized RDF triples are represented here graphically in Figure 14. This figure introduces no new kinds of triples, but just puts together all the kinds that have been illustrated above.
Figure 14: a selection of association triples from VRDF represented graphically
Figure 14 excludes triples representing direct properties of LOC structures and definitions – these are illustrated in Figure 4.
The InLOC Information Model allows sub-structures of a LOCstructure to exist. This allows the inclusion of one LOCstructure, complete with its LOCdefinitions and LOCassociations, inside another LOCstructure, while retaining its identity.
However, in RDF this is not possible in the same way. Many systems using RDF are able to distinguish distinguish separate RDF graphs, but Turtle and N-Triples do not have the concept of a graph within a file. Therefore, for simple systems and tools it is recommended that only one LOCstructure is present in any one InLOC RDF file.
It is still possible to have sub-structures represented in RDF, but it is not possible to represent a LOCassociation as being inside or outside a sub-structure. Therefore, if sub-structures are used, the RDF will be equivalent to an XML structure where all the LOCassociations are contained within the outermost LOCstructure, and not within any of the sub-structures.
Adding extra information that is not described here in RDF format does not normally disrupt the existing information. So, for example, there may be agreed a way of adding an ISBN to a document. This could be done directly, simply introducing an extra triple. The subject IRI would be, as before, "VRDF:vitaerdf", and the object could be given as the IRI "urn:isbn:978-1-906774-18-9". The predicate could be anything agreed that represents the ISBN property.
Any extra properties added in this way, which are not specified by InLOC, may be ignored or discarded by any receiving system.
The tables describing the InLOC properties and relationships, to be found through the InLOC properties page, include various equivalent IRIs to the ones defined for InLOC. While in XML it takes more effort to process these alternative terms, in RDF it is very simply a matter of specifying them as equivalent, and accepting them as input to any InLOC compliant system. This could be done with a simple pre-processing step of substituting the InLOC terms for their equivalent terms. Alternatively, any output or export could, according to preference, use any of the other defined IRIs instead of the InLOC ones.
Following the practice accomodated by schema.org, it may be that triples expecting an RDF object of one of the classes labelled "other resource" or "supplementary blank node" (in Figure 2) may instead be found to have a literal as RDF object. This could be for associative "LOCrel" predicates, "by" predicates, "hasScheme" or "hasObject" predicates. If an unexpected literal value is encountered in these places, it should be interpreted as if there were a supplementary blank node, and that node had a label property with the given literal as its value.
As can be seen from the examples above, the naturalized style of RDF appears greatly preferable to a style following the original model, from the points of view of compactness, ease of understanding, and ease of query formulation. Therefore, this is the proposed binding.
This ontology using RDF Schema terms is given in Turtle format. It has not been rigorously checked, and may be altered in response to the feedback from any implementation that uses it.
Here is a description of the process for converting InLOC naturalized RDF triples to InLOC XML, where there is exactly one LOC structure. It may be used as the basis for creating software to do this automatically.
There are six types of statements that may occur in InLOC naturalized RDF:
- directives (in Turtle but not N-Triples representations);
- three kinds of triples with LOCstructures or LOCdefinitions as subjects
- "LOC" triples, with predicate "a" (in Turtle) or "rdf:type" (in N-Triples), declaring a LOCstructure or LOCdefinition;
- "direct" triples, with direct properties as predicates and literal or other resource objects, which must be represented in the correct order within the relevant LOCstructure or LOCdefinition XML;
- "association" triples, with the other property predicates defined by InLOC, signifying a LOCassociation;
- "secondary" triples, having as subject an association resource, and as predicate "inloc:hasScheme" or "inloc:hasObject" or "inloc:number";
- "supplementary" triples, with predicates "inloc:label", "inloc:id", representing information for InLOC scheme and object ("inloc:id" is just to preserve non-IRI identifiers).
Any algorithm needs to keep a record of which triples have been "processed". Triples that may be processed more than once are those with "supplementary" predicates. All other triples should be processed only once. The algorithm should stop when all triples have been processed.
To generate InLOC XML, the first step is to find the identifier of the main LOCstructure. Then:
- see if the LOC structure has a language (default language);
- create the LOCstructure XML start tag;
- next, process direct properties of this LOCstructure, outputting them in the correct order;
- then deal with the remaining triples;
- lastly, when all triples have been processed, output the XML end tag for the main LOCstructure.
To process the remaining triples involves stepping through them, passing over ones that do not initiate any LOCstructure or LOCdefinition or LOCassociation, until the end, picking up other ones as part of processing these. The order of processing can be varied, to suit any particular view on the best ordering for these elements within the overall LOCstructure.
A "LOC" triple initiates the output of a LOCstructure or LOCdefinition. A LOC triple is processed together with all "direct" triples with the same subject. The XML for the LOCstructure or LOCdefinition must output the direct properties in the right order.
An "association" triple initiates the output of a LOCassociation XML element. An association triple is processed together with all "secondary" triples whose subjects are the same as the object of the association triple (whether that is an identified resource or a blank node), and also any "supplementary" triples whose subject is the same as the object of those secondary triples. As noted above, "supplementary" triples with non-blank subjects may be processed more than once. Blank nodes are naturally taken into account just the same as resources with IRIs. Note that, in the XML binding, a LOCassociation must have a subject, a scheme and an object. If there is no hasObject triple alongside a hasScheme triple, an empty XML object must be generated (e.g. "<object />").
Following these rules alone, it is possible that some "direct", "supplementary" or "secondary" triples are not processed, as their subjects cannot be found as appropriate predicates or objects in other triples. Any validation process for InLOC RDF, and any conversion process from InLOC RDF to InLOC XML, should warn of the occurrence of any such triples.
- The W3C RDF pages
- W3C RDF Primer
- N-Triples from RDF test cases
- Wikipedia Resource Description Framework