Agenda
- Review of vocabulary pages
- comments from Arwe on TURTLE vocabulary file
Minutes:
Attendees: Joe Ross, John Arwe, Tuan Dang, Martine Wedlake
Storage Volume is in here - thought we were pulling that from external.
If it stays, it has a lower case r at start of its comment.
Yes, that’s the “worst” thing I can say about the classes so clearly you’ve got the pattern.
(answer) StorageVolume will stay in vocabulary but no naming rule will be defined in the spec as we have no requirements yet for reconciliation. Only use right now is for Performance Monitoring to associate metrics to a resource. Martine will propose scenarios at later date when we need to deal with reconciliation of storage resources
Properties need a bit more work.
At the vocabulary level, there is no “class-property” binding, e.g. mfr to CS/SWServer, so those SeeAlso’s are misleading one could argue (I personally would argue that mildly). It would be very reasonable to SeeAlso the reconciliation spec for those classes (subtle difference, I realize).
Where you’re “punting” off to IETF/IANA and similar, seeAlso is a good idea too. I use comments in the Turtle to help me remember where I want to insert those “someday”.
(Tuan) fix vocabulary file to remove extranuous seeAlso. For classes, do seeAlso to point to the resource definitions in the spec
They also have SeeAlso values of crtv:ComputerSystem and similar, which (mind your socks) is not semantically valid. I think any23 is probably implemented using Jena, and I think Jena has a bug here. But I would not mind a second opinion, and validating my view requires a bit of Jena coding. The key is that Turtle does allow that syntax (my reading of the Submission Jena should be written to, and the Last Call now out). RDF allows it syntactically (because crtv:ComputerSystem looks like a URI syntactically, whose scheme is “crtrv” and whose scheme-specific-portion is “ComputerSystem”). If you take your RDF/XML and convert it to N-triples (which has no base/prefix directives), you’ll see the following (verified with any23 and w3c’s validator). Neither says it’s invalid, but look a the object value … the crtv: has not been replaced with the nsURI as you’d expect.
http://open-services.net/ns/crtv#manufacturer http://www.w3.org/2000/01/rdf-schema#seeAlso .
http://open-services.net/ns/crtv#manufacturer http://www.w3.org/2000/01/rdf-schema#seeAlso .
I found this working on PerfMon’s examples, because I did pretty much as you did … created a nice compact Turtle, read it into Jena, wrote it back out as RDF/XML, etc. At some point I had a conv with ITM where first I told them to use rdf:resource=”crtv:CS” and then had to back off after I ran into a statement that XML attribute values were not treated as qualified names, only the element/attribute names were. This was unbelievably hard to nail down in the specs (that statement might be true of XML, but this is RDF/XML, and the latter could have layered qnames in attribute values on top). Finally I found the following citations in RDF/XML that convinced me - see if you read them as I do, that a base URI is used but namespace prefixes are NOT used when resolving RDF URI references.
1 http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/#section-Infoset-Grammar-Notation under 6.3.3, resolve(e,s) definition
[2] http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/#section-Infoset-Grammar-Notation the BNF … which did not get me far. If I follow the RDF URI reference production, it just says “it’s a URI”. Which is evidence that ns prefixes are uninvolved, but hardly definitive.
[3] http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/#resourceAttr the production for rdf:resource, again … unhelpful
[4] http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/#emptyPropertyElt is the production that covers cases like your seeAlso. This was the definitive one for me.
It’s possible there is some Jena option to control this behavior (it might be a Jena “value add” instead of living in the RDF/XML layer, so a “strict” option on Jena might then disable it). I took a cursory look but found none.
BTW, since you have many open-services.net URLs between rdf:about, definedBy, seeAlso, you could shorten all those by setting a base URI. Either just the .net portion to cover all of them, or the full ns (which misses the wiki ones). The annoying part is, since Turtle lacks this restriction of qnames in attribute values, making the RDF/XML friendlier involves propagating this “hack” back into the Turtle.
