Chronological Thread 

< Chronological >      < Thread >

---

Andrew Miller wrote:
> 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).

hmmm...my example above seems to resolve the URIs as I expect when I put
it through the RDF validator, and I can change the parabola.xml to
something else for some of them and it'll resolve the relative URLs ok
as well - but maybe that is processor dependent and may not always work?

Are you just suggesting that it would be better to simply have
rdf:resource="parabola.xml#parabola_simulation" rather than use the
xml:base attribute? Not sure why I didn't do that originally, makes more
sense.

>> 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).

ok - I think something just dropped into place. So in this case what I
would do is define my simulation like

<cs:simulation>
<rdf:Description rdf:ID="simulation-ID">
<cs:simulationName>cool_name</cs:simulationName>
...
</rdf:Description>
</cs:simulation>

and then I can use that ID to reference the simulation. Is that making
sense now? Probably a good thing that this discussion is starting to
make me work out how RDF actually works :-)

> 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?

Possibly it could be clearer, but that is certainly the way I understand
it. I'm just using the RDF/XML as a way that I almost understand to
illustrate the RDF...

>
>> 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.

agreed.

> 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.

do you really mean graph nodes, or do you mean cs:simulation nodes? If
you do mean graph nodes then I'm even more confused than I thought...

To me it makes sense that simulation(s) are defined within a model, and
in some cases it makes sense to also define graphs within a model.
However, there are also many cases where you want to plot graphs using
data from multiple models. So this means either having graph metadata
external to the models and simulations or creating a single super model
that imports all the models of interest and using that. I can see cases
where both of these approaches will useful.


Thanks,
David.


--
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: david.nickerson at nus.edu.sg

---

• [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.