Bogus property as:id
tpluscode opened this issue · 3 comments
Please Indicate One:
- Editorial
- Question
- Feedback
- Blocking Issue
- Non-Blocking Issue
Please Describe the Issue:
The RDF vocabulary of Activity Stream includes a property http://www.w3.org/ns/activitystreams#id
.
By looking at the spec it seems to represent a mapping to JSON-LD's @id
keyword much like as:type
does.
However, it has no place in the RDF vocabulary.
<http://www.w3.org/ns/activitystreams#id> a owl:DatatypeProperty,
owl:DeprecatedProperty,
owl:FunctionalProperty ;
rdfs:label "id"@en ;
rdfs:domain [ a owl:Class ;
owl:unionOf ( <http://www.w3.org/ns/activitystreams#Link> <http://www.w3.org/ns/activitystreams#Object> ) ] ;
rdfs:range xsd:anyURI .
Described as above, it does not make sense. The @id
field in a JSON-LD document is only a syntactic feature to represent given resource's identity. It is by no means a property of that resource. Thus, is does not represent a predicate.
Not to mention the rdfs:range xsd:anyURI
which would indicate a string literal, where the ID of a resource would in fact be an actual Named Node URI, or... blank node.
Please remove this from the vocabulary
Our OWL schema is non-normative and best-effort, and not maintained by the working group. The normative reference for the id and type aliases is https://www.w3.org/TR/activitystreams-vocabulary/#dfn-id (also, I believe referring to them as http://www.w3.org/ns/activitystreams#id and http://www.w3.org/ns/activitystreams#type is technically incorrect? since the JSON-LD schema defines them as aliases of pieces of core syntax, not URIs in their own right, as you mention)
Our OWL schema is non-normative and best-effort, and not maintained by the working group.
It's not generated automatically in any way? A PR is welcome then?
In the case of type
, you could get away with mapping it to rdf:type
. This is pretty much what JSON-LD's @type
keyword represents. It is still only JSON-LD-specific syntactic construct. Like a
in turtle's <foo> a <bar>
notation.
Bottom line, yes, I would not refer to either id
or type
as URIs, much less from the as:
namespace
We included the mapping of id
to @id
and type
to @type
for backwards-compatibility reasons with Activity Streams 1.0. I think there may be other reasons it was included, but they're not immediately at hand. I'll see what I can do to dig up the justification.
However, these two properties are '''widely''' implemented in a number of processors, and removing or deprecating them would be a big problem for a large number of implementers. Unless there's a better case for removing or deprecating them than conceptual purity, I would prefer that they remain.