Symmetry

[gymel]

As the introduction states nicely, Beacon files denotate a mapping function: From "Identifiers" or URIs to URLs, URIs and maybe "Identifiers".

To stress the symmetry the template fields PREFIX and TARGET should be named SOURCE and TARGET and obey the same syntax rules.

To make things like "{ID}" clearer, the placeholders should be named "SRCID" and "TRGID" (both may occur in targets, there are even examples for mixtures and repetitions [and alas also target placeholders split in two parts with a repetitive element between them]). However TRGID should be forbidden for the SOURCE template.

[nichtich]

Yes, PREFIX could better be named TARGET and it could also allow for the {ID} parameter, but a prefix is simpler and (most important) it alrady has been established. Making all existing BEACON dumps and documentations invalid does not value the change of a name in my opinion.

I first experimented with two template parameters {ID} and {TARGET} but this made things only more complicated. If there is only one parameter {ID} one cannot confuse it. And whenever you have to forbidd some case, it may be easier to not make this case possible at all. So better keep it simple - this is the most important design rule at all.

[dr0i]

The assymetry ever confuses me and I would strongly hope that this is fixed via: sed 's#PREFIX#SOURCE#g' Why is it asymmetric?

PREFIX implies the existance of SUFFIX TARGET implies the existance of SOURCE

And my, whats the semantic of "prefix" and "suffix" anyway? Its only confusing in context of a BEACON. A strong point is, of course, the new documentation: you ever speak of "source" and "target", but then its said that PREFIX denotes "source" and TARGET denotes "target". That's counterintuitive and I think way more disturbing (especially for newbies!) then to change the small amount of existing BEACONS (that's at least my opinion and I am encouraged because this issue already exists. It was the second thing come into my mind besides "ah - BEACON is CSV with metadata".) BTW - as the new documentation introduces semantics one could also use: s#PREFIX#SUBJECT s#TARGET#OBJECT s#QUALIFIER#PREDICATE ?![1] ... but I wouldnot insist of this idea.

[1] I admit to be confused because the QUALIFIER specifies the relation type of relations between link target and link qualifier. Help me with that: all I want is a relation between A and B:

PREFIX: http://example.org/

TARGET: http://example.com/

abc|12

whats missing to get:

http://example.org/abc rdfs:seeAlso http://example.com/12 ?

[gymel]

This is a main area of things still to be sorted out:

• A Beacon file might serve as a mapping between (foreign) identifiers and URIs. Or between URIs. Or between identifiers alone (but it probably should be assumed that there are at least source identifiers and target _URI_s).
• The relation between Identifiers and respective URIs (source and target) would be controlled by URI templates, RFC 6570
• Some kind of PREFIX also appears in VoID and serves as a contrived(?) URI for the "vocabulary used", e.g. the authority "file" itself, c.f. http://www.w3.org/TR/void/#vocabularies (4.3). Here I see similarities to namespaces in XML.
• PREFIX(es) historically (wrt Beacon files) seem to have tehir root in the shorthand notation string like specified for Turtle (and thus apply only if there are source and target URIs) See http://www.w3.org/TR/void/#pattern (4.2)

In the predominant examples "http://d-nb.info.gnd/" seems to serve all three purposes:

• How to construct an operational URI from an Identifier
• What is the meaning of the Identifiers used (VoID coins the notion of "datasets" stressing the "social dimension" added by the fact that someone has crafted a meaningful collection), e.g. how to identify the authority file or similar context used in the beacon file
• How to (maybe adhoc) derive shorthand "identifiers" from URIs by stripping a common prefix

I'm still struggling to grasp the subtle transitions at work when translating a "data line" abc|12 to a working hyperlink bearing a certain meaning...

[nichtich]

I created issue #15 to rename meta field PREFIX to SOURCE. There is no semantic involved in this name change, it's just a matter of convenience to minimize confusion - the meta field could also be named 'FOOBAR' or anything, it's just a name.

About the question how to get:

http://example.org/abc rdfs:seeAlso http://example.com/12 

the relation type of all links in a Beacon dump is defined by the link meta field see spec with default value http://www.w3.org/2000/01/rdf-schema#seeAlso. You can make this explicit in Beacon text format like this:

#PREFIX: http://example.org/
#TARGET: http://example.com/
#LINK: http://www.w3.org/2000/01/rdf-schema#seeAlso
abc||12

Please note that there are two vertical bars between source and target!

This relation type can be translated to an as RDF predicate, if Beacon links are mapped to RDF. If Beacon links are mapped to other kinds of hyperlinks, there is not one single interpretation, because there is not one definiton of "hyperlink" (for instance an <a> element in HTML, but which parts of the HTML are also part of the hyperlink?). A possible translation of a Beacon link with relation type rdfs:seeAlso could also be a <span> element:

<span>See also <a href="http://example.org/abc">12 documents in the catalog</a></span>

[dr0i]

thanks, that made it clear :)