W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > January 2016

Re: ISSUE-95 Discussions

From: Arthur Ryman <arthur.ryman@gmail.com>
Date: Thu, 21 Jan 2016 13:48:49 -0500
Message-ID: <CAApBiOm1kYXtc=yowr4j7U_4xb-ezORq+cSJ7Za0rPBcMEWVTA@mail.gmail.com>
To: Holger Knublauch <holger@topquadrant.com>
Cc: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Holger,

Yes, that's the latest version of shacl-vocab.ttl.
Yes, let's settle on the parts of the vocab that are uncontroversial.

I organized the Turtle file into three sections: classes, properties,
individuals. They are alphabetical within each section. I have found
that organization makes it easy to find things. However, if you have a
better organization, go ahead and rearrange the terms.

Here responses to your suggestions follow:

> Some suggestions on the vocabulary's format:
>
> - Following other vocabularies such as SKOS, the graph URI and owl:Ontology
> should be http://www.w3.org/ns/shacl, without #. We don't need to use
> owl:Ontology for this pure RDFS model - it could just be an rdfs:Resource.

I am following the W3C conventions. Have a look at, e.g.
https://www.w3.org/2000/01/rdf-schema#
Here is a snippet:

<http://www.w3.org/2000/01/rdf-schema#> a owl:Ontology ;
dc:title "The RDF Schema vocabulary (RDFS)" .

rdfs:Resource a rdfs:Class ;
rdfs:isDefinedBy <http://www.w3.org/2000/01/rdf-schema#> ;
rdfs:label "Resource" ;
rdfs:comment "The class resource, everything." .

rdfs:Class a rdfs:Class ;
rdfs:isDefinedBy <http://www.w3.org/2000/01/rdf-schema#> ;
rdfs:label "Class" ;
rdfs:comment "The class of classes." ;
rdfs:subClassOf rdfs:Resource .

Note the use of owl:Ontology and rdfs:isDefinedBy. The ontology URI is
the same as the namespace. The terms defined by the ontology are
linked to the ontology using rdfs:isDefinedBy.


> - I think we should minimize dependencies on other namespaces, i.e.
> references to oslc should be removed. Likewise, dcterms can often be
> replaced with rdfs:label and rdfs:comment.

Disagree. We should make use of other namespaces when they define the
terms we need. Again, refer to the RDF vocabulary which uses DC. The
OSLC namespace is only there for defining namespace prefixes which
appear in the HTML generated from the Turtle.

> - When we use rdf:XMLLiteral, then the values should be valid XML (which
> isn't the case in your file), so we should either switch to rdf:HTML or use
> plain text (xsd:string without hyperlinks).

They are valid XML fragments AFAIK. The RDF spec does not require them
to have root elements. Where do you think they are not valid XML? I am
surprised that Jena+XSLT would work with invalid XML. The use of
XMLLiteral versus HTML is historical since HTML was only added
recently. Also, XML is easy to process. The conversion to an HTML
document is currently done by converting the Turtle to RDF/XML using
Jena, and then applying an XSLT to the XML to generate HTML. These
files are also in github. A more modern approach would be to extend
ReSpec and do this all in Javascript. Let's leave the XMLLiteral in
until we can replace the XSLT with Javascript.

> - I think it's premature to talk about vs:term_status = stable for anything,
> so maybe we should just drop these triples for now.

I think we have many uncontroversial terms so marking them as stable
is useful for the working group. Feel free to change the status of any
term that you think is controversial.

> - rdfs:isDefinedBy is just noise and extra maintenance burden for now; I
> would drop them.

No, rdfs:isDefinedBy is the way to link an RDF term with its ontology.
My XSLT relies on that. It also lets vocab information live in a
triple store with other vocabs. You can then get all the terms for a
given vocab using a SPARQL query.

> - rdfs:labels should be presentation names, not just the local names of the
> URIs, e.g. "source template" instead of "sourceTemplate".

OK, I just used the local names, but if you'd like to use less
computerese names, please go ahead and change them.

>
> Holger

-- Arthur
Received on Thursday, 21 January 2016 18:49:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:29 UTC