Chronological Thread 

< Chronological >      < Thread >

---

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] Graphing metadata, David Nickerson, 10/31/2006
  • [cellml-discussion] Graphing metadata, Andrew Miller, 10/31/2006
    • [cellml-discussion] Graphing metadata, David Nickerson, 10/31/2006
      • [cellml-discussion] Graphing metadata, Andrew Miller, 10/31/2006
        • [cellml-discussion] Graphing metadata, David Nickerson, 10/31/2006

---

Archive powered by MHonArc 2.6.18.