Chronological Thread 

< Chronological >      < Thread >

---

David Nickerson wrote:
>
>> 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 :-)
>
Yes, that will do what you want (I am assuming, of course, that
cs:simulation is a propertyElt of some sort).
>
>> 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
>
Sorry, it should be simulation nodes at least (although perhaps
commenting on graphs would also be useful, for example, "graph
http://www.cellml.org/models/myModel/download#mygraph demonstrates that
(reified statement node)" could be useful metadata for knowledge
management systems, as could access to almost any node in the RDF
graph). Suggesting that anonymous nodes not be used could be one
approach, although it would result in harder to read metadata in the
hand-coded case (the model repository will mess up nicely hand-optimised
RDF/XML anyway, though).
> 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

---

• [cellml-discussion] Graphing metadata, Andrew Miller, 11/01/2006
  • [cellml-discussion] Graphing metadata, David Nickerson, 11/01/2006

---

Archive powered by MHonArc 2.6.18.