Closed afs closed 2 years ago
Is the idea to simply introduce such a URI without explicitly defining any specific semantics for it, or should it also have a specific semantics? For instance, assuming rdfstar:EmbTriple
would be this URI, should the following assertion lead to any special inference? If yes, what inference?
:arbitraryURI rdf:type rdfstar:EmbTriple .
I mean, the URI :arbitraryURI
clearly is not an embedded triple.
This is the same situation as rdfs:Literal
.
c.f. :arbitraryURI rdf:type rdfs:Literal
.
No entailments.
It should go into rdf:
- other work has put URis into that namespace (e.g. rdf:PlainLiteral
, rdf:JSON
).
Later migration of URIs is extremely problematic on the web. c.f. We are stuck with application/x-www-form-urlencoded
. Nowadays good practice is to use the unregistered but intended final name for a MIME type.
Makes sense. Thanks for the clarification.
Sorry @afs but I don't get it. Do you mean to update the rdf vocab at https://www.w3.org/1999/02/22-rdf-syntax-ns#, and add sth likerdf:embTriple
? Wouldn't be better to have a separate namespace of a vocab with specific axioms ?
(As "Literal" is in RDFS, this should be as well, Never can remember the split ...)
Just write in the RDF-star report "we define rdfs:TripleTerm as the class of all RDF-star embedded triples" (or whatever name) and include like:
rdfs:Literal a rdfs:Class ;
rdfs:isDefinedBy <http://www.w3.org/2000/01/rdf-schema#> ;
rdfs:label "Literal" ;
rdfs:comment "The class of literal values, eg. textual strings and integers." ;
rdfs:subClassOf rdfs:Resource .
RDF-star is a proposal for a new feature to RDF and any future WG would incorporate it.
A separate namespace is effectively permanent. Like the RDF/RDFS split is (hindsight) unnecessary, a third namespace is confusing.
OK. That's more like a suggestion to add in the draft. In that case, if we have
rdfs:TripleTerm a rdfs:Class ;
rdfs:isDefinedBy <http://www.w3.org/2000/01/rdf-schema#> ;
rdfs:label "Triple Term"@en ;
rdfs:comment "The class of triple terms for rdf-star."@en ;
rdfs:subClassOf rdfs:Resource .
Aren't we forcing to entail that the triple term is a rdfs:Resource
? Wouldn't this have other consequences per your comment about no entailments?
Oh wait, Maybe you meant this definition below?
rdf:TripleTerm a rdfs:Datatype ;
rdfs:label "Triple tem"@en ;
rdfs:comment "The class of all RDF-star embedded triples."@en ;
rdfs:subClassOf rdfs:Literal ;
rdfs:isDefinedBy <http://www.w3.org/1999/02/22-rdf-syntax-ns#> ;
rdfs:seeAlso <https://w3c.github.io/rdf-star/cg-spec/editors_draft.html#dfn-triple> .
BTW, who are the editors of the rdfs
vocab? They updated the vocab in 2019 without proper mention of metadata? Where are the best practices in the W3C namespaces? :)
While it behaves like a literal, (not deferenced) it isn't a subclass. It is a new RDF term along side the others. Literals can't go in the subject position.
It should go into rdf: ...
Is this CG allowed to modify the rdf: namespace ?
The text could be:
"This group proposes the following addition to the RDF/RDFS vocabulary: ...".
There isn't an active RDF-WG and (e.g.) JSON-LD WG added several items to the RDF/RDFS namespaces.
This is work within the RDF-DEV CG so while not a WG, it is community.
Data updates slower than code. Cool URIs don't change. Existing, working systems simply don't get upgraded in any practical, finite timeframe.
During the years of transition, there are two different URIs which is horrible.
Just saw that this issue is a duplicate of #77
Given that the proposed semantics is still rather unstable and essentially quite unproven an rdf-star namespace seems more appropriate.
can be closed when #215 is merged
In order to support the use of
rdfs:range
andrdfs:domain
, the spec should have vocabulary defined for the class of all embedded triples. Specifically, a standard URI for the class.