David Nickerson wrote: > Thanks Andrew, cleared a few things up. So now for some more > ideas/questions... > > When defining a graph outside the scope of a single model or when > combining results from multiple model's, does it still make sense to use > the about="modelid" ? > > I have been looking at how to define my graph externally and came up > with this: > > <rdf:RDF > xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; > xmlns:cs="http://www.cellml.org/metadata/simulation/1.0#"; > xmlns:cg="http://www.cellml.org/metadata/graphs/1.0#";> > <rdf:Description> > <cg:graph rdf:parseType="Resource"> > <cg:traces rdf:parseType="Collection"> > <rdf:Description> > <cg:type > rdf:resource="http://www.cellml.org/metadata/graphs/1.0#line"/> > <cg:colour>#ff0000</cg:colour> > <cg:x-variable xml:base="parabola.xml" rdf:parseType="Resource"> > <cg:simulation rdf:resource="#parabola_simulation"/> > <cg:variable rdf:resource="#time"/> > </cg:x-variable> > <cg:y-variable xml:base="parabola.xml" rdf:parseType="Resource"> > <cg:simulation rdf:resource="#parabola_simulation"/> > <cg:variable rdf:resource="#y"/> > </cg:y-variable> > </rdf:Description> > <rdf:Description> > <cg:type > rdf:resource="http://www.cellml.org/metadata/graphs/1.0#scatter"/> > <cg:colour>#0000ff</cg:colour> > <cg:glyph > rdf:resource="http://www.cellml.org/metadata/graphs/1.0#circles"/> > <cg:x-variable xml:base="parabola.xml" rdf:parseType="Resource"> > <cg:simulation > rdf:resource="#parabola_simulation_large_maxDT"/> > <cg:variable rdf:resource="#time"/> > </cg:x-variable> > <cg:y-variable xml:base="parabola.xml" rdf:parseType="Resource"> > <cg:simulation > rdf:resource="#parabola_simulation_large_maxDT"/> > <cg:variable rdf:resource="#y"/> > </cg:y-variable> > </rdf:Description> > </cg:traces> > </cg:graph> > </rdf:Description> > </rdf:RDF> > > In this example, all the xml-base attributes are the same so I could > just specify it once on the top element, but potentially they could all > be different. I presume you are aware that absolute URLs are allowed in rdf:about as well as relative ones? If you are going to use xml:base, you need to give a suitable absolute URL, as only one base URL is used to resolve relative URLs (i.e. it will not resolve against each base URL until it gets an absolute URL). Refer to section 5.2 of rfc2396.txt: "Note that only the scheme component is required to be present in the base URI; the other components may be empty or undefined." So you need at least an http: or file: on your base URI (and obviously, a path as well if you are not going to give it in your relative URIs). > The rdf:resource's for the cg:variable reference > cmeta:id's defined on the variable's from the simulation's model (as > defined in the spec) but the cg:simulation references the cs:simulation > via the rdf:ID on the cs:simulation, eg, > > <cs:simulation rdf:ID="parabola_simulation_large_maxDT" > rdf:parseType="Resource"> > <cs:simulationName>parabola_large_maxDT</cs:simulationName> > ... > </cs:simulation> > > I have used the validator tool Andrew mentioned, and the graph I get out > looks like what I want for this graph metadata, and if I mangle > simulation metadata into the RDF I paste into the validator everything > seems to point to the right places....but given Andrew's description > below I'm guessing I shouldn't be using rdf:ID's in this way? > You can use rdf:ID, but you have to be careful where you put it, because not all elements are treated equally in RDF/XML. In terms of the parser rules specified in the RDF/XML specification:
Section 7.2.11 (for nodeElt) says: If there is an attribute /a/ with /a/.URI <http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/#eventterm-attribute-URI> == |rdf:ID|, then /e/.subject <http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/#eventterm-element-subject> := uri(identifier <http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/#eventterm-identifier-identifier> := resolve(/e/, concat("#", /a/.string-value <http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/#eventterm-attribute-string-value>))). So if you are putting the rdf:ID on a nodeElt, you are setting the subject of the node element, which is what you want. However, if you put the rdf:ID on a resourcePropertyElt, literalPropertyElt, parseTypeLiteralPropertyElt, parseTypeResourcePropertyElt, parseTypeCollectionPropertyElt, or emptyPropertyElt, you are reifying the statement (i.e. creating a new node describing the statement, so you can make a statement about the statement), which is not what you want to do. Therefore, you have to be aware of the relationship between RDF/XML and the RDF data model, and make sure you put your rdf:ID in the right place (as with any other attribute in RDF). BTW the specification is supposed to describe what the RDF graph will look like, and not constrain the RDF/XML that you can use. The RDF/XML is merely provided to give a non-normative example of RDF/XML which results in a valid RDF graph. Perhaps this needs to be made clearer in the specification? > And I agree that it would be good to be able to define a graph > externally for any simulation, so maybe we need something to say that > while the blank node approach is valid it is more useful not to use > them? Or do we actually want to define this as part of the specification? > I don't think we should be constraining the RDF/XML that can be used to encode the RDF, because this is supposed to be an RDF level specification. Because anonymous nodes are convenience feature of RDF/XML, rather than part of RDF proper, it wouldn't really make sense to put a normative constraint at this level (after all, people could be using languages other than RDF/XML to represent the data anyway). Simply putting the document through a parse / serialise cycle on any of the existing RDF software would remove anonymous nodes anyway, since most parsers assign the nodes a URL, and the serialisers just spit this out again. I wouldn't be opposed, however, to adding a style guideline recommending that graph nodes be given an explicit URL (we actually say that they would normally be an anonymous node at the moment), so they can be referenced. The only disadvantages of this is that the resulting RDF/XML is longer and more deeply nested, and that people could be tempted to perform open-world extensions to existing simulations, rather than making a copy at a new URL. Best regards, Andrew _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
